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

Hi Kipp,

I know I replied to this message, and I know that you replied back,  
but I can't find either message now. Doesn't really matter, but there  
is one aspect of giving the arrays in your way that I don't like. The  
problem is that the order in which your solverOptions are given,  
matters. I view that as potentially dangerous. There is no indication  
of this in the schema, and I think it is an accident waiting to  
happen, particularly if one of the entries happens to be zero.

Cheers

gus