[Os-project-managers] phone meeting

[R. Kipp Martin]

Hi Gus:


> serious drawback. Ideally, if the solver developer decides to make
> available another solver option, There should be _no_ change to the
> OSSolverInterface. The user puts another line in an osol file, we parse
> (under "other") and ship it to the solver. The solver then accepts the
> option or ignores it, as appropriate. However, things get hairy when

What do you mean by we parse under "other"? If the solver developer adds 
a new option then in the osol file there is just

  <solverOption name="newOption" value="newValue" solver="xxx" type="yyy"/>

and it is treated like all the other options  <solverOptions> under 
<optimization>.


> there are arrays of values (such as starting points or warmstart bases)
> to be shipped across. I am not sure that doing a one-off in this case is
> ideal. It seems that the three types of options, integer, double (or
> "numeric") and string aren't quite good enough; we should also talk
> about arrays of integers and doubles --- although this opens up
> Pandora's box of dense versus sparse arrays, two- and higher dimensional
> arrays, etc.

Here is one way to handle arrays. See the attached OSoL file. It is used 
in an actual vehicle routing problem I am working on. For example, there 
is an array of demands. Each node in the network has an associated 
demand. I need an array of demands with size equal to the number of 
nodes in the network.  See in the attached file, all of the solver 
options like:

   <solverOption name="demand" value="3" solver="routeSolver" 
type="integer" description="N03"/>

So at node N03 there is a demand of 3. This is parsed using code in

OS/applications/columnGen/code/OSBearcatSolverXij.cpp

in lines 1935-1943.  Each demand value is put into a vector called 
demand. Then after the OSoL file is read, the demands are put into the 
integer array m_demand. See lines 2121-2130.  A similar thing is done 
with the arc costs that have OSoL like this

<solverOption name="cost" value="1.2" solver="routeSolver" type="double" 
description="H02a.N04"/>

This is actually works quite well.

> So I do not know how best to take this forward. I think it makes sense
> to try to talk to Matt and Lou before their efforts take on too much shape.

When we meet next week let's come up with a strategy for collaborating 
with Lou and Matt.

Cheers




-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: colgen12b.osol
Type: text/xml
Size: 21016 bytes
Desc: not available
Url : http://list.coin-or.org/pipermail/os-project-managers/attachments/20110519/8d19e4ee/attachment.xml