[Coin-discuss] Open-source Modeling Languages

[Leo Lopes]

Thanks, Bill, for the update on the status of the some of the
different Python-based modeling systems.

I haven't contributed to this thread before because this thread
started with a discussion of Nonlinear Programming. NLP is very
important. However, my modeling system was designed to study Systems
Engineering aspects of developing large complicated dynamic models.
Thus, it supports introspection; modularization; instance and model
separation; object oriented modeling; and other SE aspects, but does
not support NLP.

Cheers,
Leo.

On Nov 27, 2007 7:12 AM, Hart, William E <wehart at sandia.gov> wrote:
>
> 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
> >
> >
>
>
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>



-- 
========================================================================
Leonardo B. Lopes                                    leo at sie.arizona.edu
Assistant Professor                                        (520)621-2342
SIE - University of Arizona  http://www.sie.arizona.edu/faculty/leolopes