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