[Os-project-managers] phone meeting

[Horand Gassmann]

"R. Kipp Martin" <kmartin at chicagobooth.edu> wrote:

> 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.

I do not know how well this scales. You will have to match variables  
by their name, which is probably time consuming, and what if you do  
not have names?

I would have thought that the following should work better:

<variables numberOfOtherOptions="1">
     <other numberVar="..." name="cost" solver="routeSolver" type="double">
         <var idx="0" name="H01a.H02a" value="100"/>
         ...


>> 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.

Sounds good.

Cheers

gus