[Coin-discuss] Open-source Modeling Languages

[Brian Borchers]

>As I understand it (from my outside viewpoint as a user), the intention 
>is not for most normal users to ever actually write code to produce a 
>file in XML format. 

First, although many normal users produce models using a modeling
language like AMPL, many other other users produce their problem
instances using conventional programming languages like C.

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.  

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.  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.  

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.

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.

I doubt that anyone who currently uses the first approach would find
it easier/better to use OS, because there isn't much that you could do
with OS that you couldn't do with the existing interfaces.  I'm also
not aware of any of the authors of the MATLAB packages for SDP
modeling who have expressed an intention to implement OS interfaces.

However, when it appears that modeling languages that use OS and
support semidefinite constraints are coming, I'll give serious
consideration to implementing an OS interface to my solver.

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.

In summary, I think that OS offers some advantages in the long run.
However, in the short run OS faces the classic "network effect."  The
old fashioned approaches are so well established that it's hard to
convince the entire network of developers and users to switch to a new
interface standard, even if it is better.  It's also not clear exactly
how much better OS is.  If you can't convince almost everyone to
switch, then the new standard won't take hold.