[Os-project-managers] OSrL problem

Horand Gassmann Horand.Gassmann at Dal.Ca
Sun Sep 2 00:54:21 EDT 2012


Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
>>
>> I'll have to kick this around a bit more. It ought to work, but maybe
>> there is a trick somewhere. What about the following scenario: AMPL can
>> have a user-defined subscript of type "binary". AMPL can only transfer
>> this as an integer, so when sending such info to the solver, it
>> translates false to 0 and true to 1 and sends that. And it can only
>> accept integer or real values, making internal translations back into
>> the original form when necessary.
>
> I am having trouble understanding this. Are you suggesting we send  
> modeling language dependent parameters to the solver interfaces?

The parameters are defined by the user/solver. The AMPL construct is  
similar in philosophy to our <other> options. Say, a solver handles  
decomposition by assigning an extra bit of information to each  
variable and constraint as to which subproblem it belongs to. The  
solver developer can call this whatever he wants, let's say he calls  
it "sub".

AMPL does not care about the name, so it allows the user to define it  
by saying

suffix sub ...;

The exact syntax does not matter, and I am too lazy to look it up.  
Values are assigned to this via

let _var[0].sub := 1;
let _var[2].sub := 1;

etc. AMPL puts this into the .nl file, so we have to put it into  
.osol. (This is what I spent most of the summer working on.)

But of course there is also the reverse direction, where a solver  
wants to put something back into AMPL, so it can be used on the next  
iteration. I want to make sure that this direction also works for us,  
as a proof of concept, and as a check that our OSrL schema is useable.  
(And as I found out, it is not useable with AMPL without a "type"  
attribute.)

And I want to be careful about it. AMPL allows the user to define four  
different types of suffixes, real, integer, binary, and string valued  
(really only an enumeration type), but it only transmits real and  
integer values, so binary and string subscripts are converted to  
integer. This is fine for sending from AMPL to osol and on to the  
solver, but I am not sure of the reverse direction. It is clear that  
the solver must convert the string-valued suffixes to integers before  
they can be sent back to AMPL, but it is less clear that they are  
handled as integers internally in the solver, as there may be other  
modeling languages that do accept strings.

How do we handle this is the user interface? The stuff comes back from  
the solver as an array of std::string (say), and gets written into the  
OSrL file as an <other> element of type "string" (say). But the ASL  
API does not accept strings, so *we* have to convert it to an integer  
(the right integer!). How can we do that without a record of the  
enumeration AMPL constructed, based on the user input? (Note that the  
suffix does not even have to be transferred from AMPL to the solver in  
the first place!)

I think there may be a fundamental flaw in all of this, but I am happy  
(ecstatic!) to be proven wrong.

Cheers

gus
-------------------------------------------------------

Horand I. Gassmann, Professor

School of Business Administration, Dalhousie University
6100 University Avenue, PO Box 15000
Halifax, Nova Scotia, Canada, B3H 4R2
ph. (902) 494-1844
fax (902) 494-1107

http://myweb.dal.ca/gassmann/



More information about the Os-project-managers mailing list