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

[R. Kipp Martin]

Hi Gus:

I am back in Chicago. I will at the office, 773-702-7456 for our meeting.

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

1) It looks like when you define gus as a suffix, you do not state 
whether it is a suffix for variables, constraints, objectives etc. Could 
it also index rows? That is, could you also have


let {j in J} row[j].gus = if (abs(x[i]) < 10) then j else 2*j;

in the same model file?

2) Have you heard anything more from David Gay?


3) What is your probability assessment that withing two years there will 
be an ASL method to let one get all of the suffix names from an nl file?

4) I assume just getting suffix names is not enough, we would need to 
know from the get method what to attach the suffix to, e.g. variable, 
row, objective, etc.

Cheers

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


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

Sent without Blackberry, Droid, iPhone, or any other
wireless device.
--