[Coin-discuss] Open-source Modeling Languages

Hart, William E wehart at sandia.gov
Tue Nov 27 09:12:38 EST 2007


Although most of this thread has focused on licensing issues, I wanted
to second Sebastian's observation that there is real utility in an
open-source modeling language.  Even in my pseudo-industrial role at
Sandia, this frequently comes up; customers want the features of a
modeling language, but they are often scared-off by the licensing
costs/requirements.

I am hoping that an alternative to FlopC++ will be available shortly.
Leo Lopez and I have independently developed Python modeling tools.
These leverage Python's expressive scripting language to support an
object-oriented semantics that is reasonably natural (I won't claim it's
as clean as something like AMPL).  As with FlopC++, the user can
leverage the flexibility of a complete programming language to develop
complex models.

I was personally motivated to protype this capability in Python because
(a) I have become frustrated with the limitations of AMPL (the
commercial modeling tool that we have available within Sandia), (b) my
customers don't want to pay for a commercial modeling tool anyway, and
(c) developing this capability in a mature scripting language freed me
from much of the grungy parts of managing a new modeling language.  [OK,
(d) I am quite familiar with Python, which has a very clean syntax that
works well in this context.] So, while this doesn't provide a customized
syntax for optimization, it does provide a flexible basis for building
up optimization modeling capabilities.

Leo and I are working on legal issues related to the release of our
software, the merge of these capabilities into a single Python
framework, and the potential integration of it into COIN-OR. Hopefully,
the code will be available within the next few months...

--Bill

> -----Original Message-----
> From: coin-discuss-bounces at list.coin-or.org 
> [mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of 
> Sebastian Nowozin
> Sent: Tuesday, November 20, 2007 10:21 AM
> To: Discussions about open source software for Operations Research
> Cc: maj at northwestern.edu; bradbell at seanet.com; 
> h-sheng at northwestern.edu
> Subject: Re: [Coin-discuss] Open-source Modeling Languages
> 
> Hello,
> 
> On Nov 20, 2007 5:35 PM, Kipp Martin 
> <kipp.martin at chicagogsb.edu> wrote:
> 
> > > [...]
> > > The OS folks can correct me if I'm wrong, but it seems 
> that the XML 
> > > file acts more like the .nl file that AMPL produces (as an 
> > > intermediate format between AMPL and a solver) than an 
> MPS file. I 
> > > doubt most people have ever looked at a .nl file. It is produced 
> > > transparently by a higher level layer and they never see it.
> 
> > Exactly! OSiL is a representation for an instance as opposed to the 
> > higher level model.  We don't expect people to really look 
> at an OSiL 
> > file. But if they did I think it would be a lot more 
> transparent then 
> > nl or mps.
> 
> But then, the question of a natural and reasonably powerful 
> open-source modeling language becomes more pressing; having 
> nice intermediate problem format like OSiL/OSrL and cutting 
> edge solvers like Ipopt, CBC or Bonmin is not going to 
> benefit a lot of users if they cannot develop good models 
> quickly in a language suited to the task, at least not the 
> non-programming users.
> 
> I have taken a look at FlopC++ and it looks really nice, 
> especially for going from a rapid prototype directly into a 
> working component of a software; but I find it hard to 
> imagine it as standard form to exchange/discuss/publish 
> models in due to the compilation dependency.
> 
> (As one being not involved at all with COIN-OR and only from 
> a user perspective, so I'm sorry if I trip on anyone's toe.)  
> If one would want to fill this gap, extending FlopC++ to 
> support nonlinear optimization might be one way to go, as it 
> is already well integrated with COIN.  Asking kindly the 
> author of GLPK for relicensing of the MathProg part of GLPK 
> under the CPL and making it a larger subset of AMPL would be 
> another option; if the latter is done within OS, all solvers 
> who could read OSiL would profit from this in the future.
> 
> Sebastian
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
> 
> 





More information about the Coin-discuss mailing list