[Os-project-managers] Some talking points re: AMPL suffixes

[Horand Gassmann]

Hi guys,

Following on from our discussion last Thursday I prepared some talking  
points about AMPL and OSoL. These should be carried forward to our  
next meeting, and perhaps to other meetings in the future.

(GAMS is likely similar, but we have less information and less  
freedom, and it is good to start somewhere; once we understand the  
AMPL mechanism we may be able to adapt to GAMS and perhaps also to MPL.)

1. AMPL captures a lot of information in the .nl file that we would  
consider solver options (and put into OSoL). AMPL does that using  
suffixes, and there are approximately 30 different suffixes that can  
be attached to variables, constraints, objectives, problems --- not  
all suffixes to all entities, though.
Examples are initial values, starting bases, branching priorities.

You can say

let {i in I} x[i].init = 3.1415;
let {i in I} x[i].status = bas;
let {i in I} x[i].priority = i;

2. Users can also define their own suffixes. They will be put into the  
.nl file as well.

For instance

suffix gus integer, >=0;
let {i in I} x[i].gus = if (abs(x[i]) < 10) then i else 2*i;

is a legal AMPL construct and results in the gus suffix being written  
to the .nl file.

3. AMPL has looping constructs that allow you to solve slightly  
modified versions of a problem successively. It is natural to want to  
use the solution of a previous run as the starting point for the next  
iteration, and AMPL allows this very easily.

4. I can see users wanting to take advantage of these features,  
perhaps not in their full generality, but in parts at least. We should  
therefore try to accommodate this if it is not too expensive. The  
problem, of course, is that all of the suffix information has to be  
taken from the .nl file and transferred to an OSoL file (perhaps into  
an existing option, as initial values, perhaps repackaged, as the  
basis status must be, perhaps as an <other> option, as in the gus  
suffix).

5. This will require us to read the .nl file and merge the parts of it  
that represent solver options with the OSoL file that the user may  
also want to specify . There are tons of questions about this:

a. Is it best to create one OSOption object from the .nl file, another  
OSOption object from the OSoL file and merge the two?

b. Which takes precedent in case there is information in both places?  
Kipp and I talked and agreed that the OSoL file is more static and the  
.nl file is more dynamic, so the .nl file probably should take  
precedent. Is this reasonable?

c. The .nl file contains very specific information, but should we be  
prepared for merging two arbitrary OSOption objects?

d. What would be the best way of doing that? Can it be done by  
recursing through the members of the OSOption class?

e. Would it be better to read the OSoL file into an OSOption object,  
and then to append the bits from the .nl file to it? This is narrower  
in scope, but is it easier/safer/better?

f. Architecturally, should we prepare an OSnl2OSoL class with  
appropriate methods? Or should we change OSnl2OSiL to OSAmpl2OSxL,  
which takes all the AMPL output (the .nl file plus the  
OSAmplClient_options string) and puts all of it into appropriate OS  
object (OSInstance, OSOption, etc., as required)?

g. Is the aforementioned simply too expensive to even contemplate? On  
Thursday with all three of us present we seemed to lean towards  
answering that one in the affirmative, but subsequently Kipp and I  
reconsidered. I don't think we came up with a conclusive answer.

Food for thought.

Cheers

gus