[Os-project-managers] OSAmplClient.cpp

[R. Kipp Martin]

Hi Guys:

I want a thread to keep track of this.

Cheers

>> Hi Gus:
>>
>>> Remember, the osol file contains not just scalar options, but also some
>>> vector options. I am most concerned about those. This is stuff that is
>>
>> Why are you concerned about these? We support vector options in OSoL.
>>
>>
>>>
>>> First, AMPL allows you to set initial values very easily, even compute
>>> them. They get put into the .nl file, so the user might expect that they
>>> get picked up by the solver. What's more, you may want to use the
>>> previous solution as a starting point. Do you really want to burden the
>>> user with having to prepare a new osol file every time?
>>
>> I can see this point if you are in AMPL and writing a script that
>> iteratively re-optimizes a model. I am not familiar with AMPL scripts,
>> but I assume you can do this sort of thing with AMPL scripting.
>>>
>>> Second, AMPL records (if we put it into the write section!) the current
>>> basis status. A user may want to use that for a warm start.
>>
>> We do not support warm starts, and it is not clear to me any solvers
>> in COIN_OR do, however I can agree that a user might want to do this.
>>>
>>> Third, AMPL has branching information. This can be computed, maybe even
>>> based on previous iterations. This is easy to do and program in AMPL,
>>> and I can see folks wanting to use that. Can we support it?
>>
>> What do you mean by support it? Isn't our philosophy to put this in an
>> OSoL file with the solver name. Then it is up to the solver to decide
>> if it supports the option. My guess is no COIN-OR solvers take
>> branching information.
>
> Cplex does, and my guess is that Cbc does also. Maybe I am not
> expressing this properly. I am talking about priorities for branching on
> integer variables.
>
>>> Fourth, it is a pain to have to write (or even modify) a long osol file
>>> just because you want to vary one option.
>>>
>>> I actually do not think it is too bad. We currently read the .nl file
>>> and parse its content into an osinstance object before we pass it to the
>>> solver; we could do the same with osoption. Any content of the
>>> OSAmplClient_options variable (which has to be a name-value pair) can
>>> then be appended to the osoption object easily. To be honest, I am not
>>
>> So I guess the algorithm is that any option in the nl file goes into
>> the optimization section and any option given by the
>> OSAmplClient_options variable (which has to be a name-value pair) are
>> for the metasolver. Is this correct dichotomy?
>
> I believe this is a reasonable dichotomy. The point is that not all AMPL
> options get put into the .nl file. In fact, only things that are indexed
> over variables, constraints or objectives show up in the .nl file; all
> other options are given in the solverName_options variable. AMPL is
> actually quite agnostic of the solver options, but it makes the
> assumption that all options are either keywords (prefixed with a minus
> sign) or else a name/value pair. This won't do for us --- it is unsafe
> to try to infer the type of an option from its current value, and there
> is no way to figure out the category. So it is best to stay clear of
> those scalar-valued options.
>
> But the vector-valued options in the .nl file should be used. Most of
> those are derived from suffixes of variables and slacks, but the nasty
> thing is that they include user-defined suffixes (which the user may
> have set up just for his own entertainment, or because the solver he
> uses has a fancy new gadget), and I do not see at this point how ASL
> will let me explore what suffixes the .nl file actually contains. This
> was the content of the email to David Gay.
>
> I since found a document in the ASL download that describes suffixes,
> but only in situations where you know what you are looking for. Say, we
> hook up to a new solver, DevelopersSolver, which has some new gizmo that
> needs input indexed over the variables. In AMPL you can set this up by
> defining a suffix 'gizmo' and supplying values for x[0].gizmo,
> x[1].gizmo, etc. AMPL knows what suffixes have been set and transfers
> this to the .nl file, but we don't know about it unless the developer
> tells us. (And in particular we can never be sure if a suffix 'gus' is
> there only for the amusement of a weirdo user, or if the DeveloperSolver
> actually looks for it. So we'd _have_ to pass it on in the hopes that it
> makes sense down the line.)
>
> If there were a way to detect the presence of gizmo values in the .nl
> file, we could grab the stuff in the same way we can grab initial values
> and basis information, and then we could transfer it properly (in
> <variables> <other>)
>
>>> overly concerned about my fourth point, but I do feel a bit strongly
>>> about the other three. AMPL puts information into the .nl file that at
>>> present we do not process. THAT can be confusing to the user.
>>
>> I wonder if there are any existing solvers that parse the .nl file for
>> options. But, yes I definitely agree with you, that as a user if I
>> have options in my .nl file I would certainly expect the solver to use
>> them.
>>
>> Just a thought -- you might to want to look at the relevant code in
>> Cbc, Bonmin, and Couenne. All of these solvers take .nl files as
>> input. Perhaps they also read the options, in which case you can look
>> at the code and copy it.
>
> Good idea!
>
> I'll check this out tomorrow.
>
> 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.
--