[Coin-discuss] modeling with GNU MathProg

[Tim Hultberg]

Hi,
    here is a small example, which shows how Benders decomposition can be 
implemented with FLOPC++.

A model has a pointer to a solver interface and its dereferncing operator (->) 
is overloaded to "point" to this solver interface. This allow us to use the 
OSI problem modification methods directly as in
  
   masterproblem->setColLower( theta().getColumn(),               
-masterproblem->getInfinity(); 

or 
	for (int j=0; j<numDistributionCenters; j++) {
	    subproblem->setRowBounds( selling(j), received.level(j), 
received.level(j));
	}

( The refernce to the row "selling(j)" is converted to an int, namely the 
corresponding row index in the model to which it belongs. To get a column 
index it is required to use the getColumn() method as in theta().getColumn(). 
)

The addRow method, used below, has not been added to the FLOPC++ distribution 
yet, but (almost) all it does is to generate a CoinPackedVector corresponding 
to the algeraic constraint expression of its argument and invokes the OSI 
addRow method (of its solver interface).

	masterproblem.addRow( theta() >= cutconst + sum(j, cutcoeff(j)*received(j)) 
);

Best regards,
                            Tim Hultberg

On Monday 19 May 2003 14:29, Alan King wrote:
> Hi Brady,
>
> Thanks for sending this around.  It's great to have an opensource version
> of AMPL.
>
> Would appreciate any thoughts out there on structuring interfaces between
> modeling methods and solver methods.
>
> For Stochastic Modeling Interface, we have to build labeling structures
> and associate them with LPs.  As a starter, I have drafted a simple
> version of a label object (implemented as a multimap) that can be
> "attached" to the OSI to facilitate referencing rows and columns.
>
> At first glance, label information really belongs to the modeling method
> side.  But specialized solver methods (eg decomposition, etc) need fast
> ways to access substructures.  These can be identified through accessing
> model information and then storing them in ways suited to the method.
>
> Maybe we should build a "model" class (OMI?) that has this function of
> communicating between modeling languages and solvers.
>
> Alan
>
> Alan King
> Mathematical Sciences, IBM Research
> http://www.research.ibm.com/
> http://www.research.ibm.com/people/k/kingaj/
>
> University Relations: University of Washington
> http://www.washington.edu
> http://www.ibm.com/university
>
>
>
>
> Brady Hunsaker <hunsaker at isye.gatech.edu>
> Sent by: coin-discuss-admin at www-124.southbury.usf.ibm.com
> 05/17/2003 08:21 PM
> Please respond to coin-discuss
>
>         To:     coin-discuss at www-124.southbury.usf.ibm.com
>         cc:
>         Subject:        [Coin-discuss] modeling with GNU MathProg
>
>
> The most recent release of GLPK (4.0) includes a parser for the
> modeling language GNU MathProg.  It's not exactly a new language,
> since it's a subset of AMPL.  It contains all of the basic
> functionality of AMPL as far as I can tell, excluding things like
> loops, for example.  So now there is an open-source way to process
> many AMPL models.
>
> Better yet, the parser provides its own API, although you have to look
> into the source code for documentation (the documentation there is
> reasonably good).
>
> The attached tarball contains a function that uses this API to read a
> model instance into an OsiSolverInterface object.  It needs to link
> against the GLPK 4.0 library as well as whatever OSI libraries are
> being used.  I included an example which reads in a model and solves
> it using CLP.
>
> I thought this was important enough to get such a function out there
> quickly.  However, I'm writing my dissertation right now, so I won't
> have time to do much more in the near future.
>
> I'm hoping that someone else will be interested enough to take on the
> task of better integrating this into OSI.  As I see it there are two
> main issues:
>
> 1. Currently OSI does not provide an easy way to identify rows or
> columns other than by index.  This is an issue since it's not
> obvious which model constraints or variables will get which
> number.  My current implementation isn't really that useful because
> of this.
>
> 2. What is the best way to include the parser?  That is, where can we
> include this or a similar function in COIN-OR?  Right now I'm
> linking against the GLPK library, which requires that the user
> install GLPK.  It would be possible to create a stand-alone parser
> for COIN-OR by extracting the necessary parts of GLPK, but this
> would have to be licensed under the GPL (I don't think that's a bad
> thing, but we probably can't do it until we're incorporated, if
> then).  Maybe there are other possibilities.
>
> I'm happy to talk about this, though I can't justify much more coding
> right now.
>
> Brady
>
> ----------------
> Brady Hunsaker
> Georgia Institute of Technology
> Program in Algorithms, Combinatorics, and Optimization
> School of Industrial and Systems Engineering
>
> E-mail address:   hunsaker at isye.gatech.edu
>
>
>
> #### ReadGNUMathProg.tar.gz has been removed from this note on May 19,
> 2003 by Alan King

-- 

Tim Hultberg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stochbenders.cpp
Type: text/x-c++src
Size: 3901 bytes
Desc: not available
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20030527/af8df675/attachment.bin>