[Coin-discuss] Open-source Modeling Languages

[Kipp Martin]

Hi Brian:

> 
> For the first group of users I agree that the XML in OS should be
> invisible, and this is really just an issue for the modeling language
> implementors and the solver implementors.  The key here is to build
> a critical mass by getting solver implementors and modeling language
> implementors to create OS interfaces for their software.  

Yes, I totally agree and we are working hard to help this happen.
> 
> For this second group of users one option is to interface to the OS
> libraries to produce OSiL, invoke the solver, and then use the OS
> libraries to read the resulting OSrL.  Another alternative would be to
> use an API like the COIN OSI. A third option is to use a solver
> specific API.  There's a lot of flexibility (for example for modifying
> a problem instance by adding cuts or setting particular solver
> options) in these API's that doesn't seem to be built into OS yet. 

Actually in the OSInstance object there are methods for adding variables 
and cuts (rows) to an existing formulation. There a number of add() and 
set() methods in the OS API.  But a thorough and complete system for 
problem modification is yet to be done.  I might add that you can use 
the OSInstance object to interact directly with a solver API and it is 
not necessary to generate OSiL.


  If
> anything it appears that OS will just allow the user to pass this
> information through to the solver without interpreting it.  In comparison,
> more traditional API's have a lot more knowledge of the solver and can
> act as "middleware" to do a lot more work for the user.

I think the OSInstance API can act as middleware in many cases if I 
understand what you are saying. Indeed the OS API can do a lot of work 
for the user. For example, when you hook OS to the LINDO API you use the 
OS get postfix method to get the problem instance in postfix which is 
what LINDO wants, so the OS API is doing work for the user. When we hook 
OS to Ipopt, we use the OSInstance object to act as middleware (through 
it algorithmic differentiation calculate methods) between the COIN-OR 
CppAD algorithmic differentiation package and Ipopt.

> 
> Although I think that the OS approach offers advantages, particularly
> for distributed computing, I wonder if the second group of users will
> find these advantages compelling enough to switch?  I'm sure that this
> second group of users will wait until the solvers have actually
> implemented OS interfaces before they even consider using OS.

Right now there is an OS interface to:

Clp
Cbc
Cplex
DyLP
Glpk
Ipopt
Knitro
Lindo
SYMPHONY
Vol


> 
> Second, as a solver writer I have to decide whether I want to produce
> a version of my solver (CSDP) that will consume OSiL and return
> solutions in OSrL.
> 
> There aren't yet any modeling languages that produce OSiL instances of
> semidefinite programming problems.  Right now, nearly everyone who
> solves semidefinite programming problems either writes their own
> programs (in MATLAB, C, or whatever) to produce problems in one of two
> commonly used formats (SDPA sparse format or MATLAB) and then passes
> the problem off to a solver or uses one of the modeling languages
> (YALMIP, SOSTOOLS, etc.) that directly make use of these defacto
> standard interfaces.


Yes, you are correct. We have yet to actually implement an OS standard 
for cone or semidefinite programming problems.

> 
> A third issue is licensing.  Since building an application that uses
> OS practically requires linking with OS libraries, you have to make
> sure that the CPL used by OS is compatible with the library that you
> use for your software.  Unfortunately, I don't think that this is true
> for the GPL.  For example, suppose that the authors of GLPK wanted to
> produce a version of their software that took as input a model in
> GLPK's modeling language, produced an OSiL instance, invoked a solver,
> and then got back the result in OSrL.  Could a binary version of this
> code be distributed under the GPL?  I believe that the answer is no.
> 
It seems like this would violate the GPL rather than the CPL.  We 
selected the CPL license because we felt in was more flexible.

Thanks

-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Graduate School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kipp.martin at chicagogsb.edu
http://gsbkip.chicagogsb.edu
http://www.coin-or.org