You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using ASL solvers, it was possible to specify an option string that had no space between option specifications. A user has provided this minimal example:
which gives a succesful Gurobi 10.0 run, even though it reports the option string to be 'outlev 0presolve 0'. When run with the MP-based Gurobi version, however, this example rejects the option string:
option gurobi_options;
Gurobi 10.0.0: Invalid value "0presolve" for option "tech:outlev"
Unknown option or invalid key "0"
tech:outlev=0
exit value 1
<BREAK>
The user was concerned because his old scripts were breaking when he tried to use them with the MP version, and he had to change to, for example,
Should we try to reproduce ASL's option processing (without spaces) in MP, or should we declare that it was an undocumented feature of ASL that we have chosen not to perpetuate?
The text was updated successfully, but these errors were encountered:
I think we should declare that it was an undocumented featured of ASL since the space should ideally be included every time. Otherwise we also get situations like the following:
I think this could work for solver options, with very low probability of breaking any existing scripts. However, a potential problem is that AMPL's option command does not know the difference between setting a solver option string and setting any other option, and thus it would also add spaces in other contexts, like this:
Using ASL solvers, it was possible to specify an option string that had no space between option specifications. A user has provided this minimal example:
which gives a succesful Gurobi 10.0 run, even though it reports the option string to be
'outlev 0presolve 0'
. When run with the MP-based Gurobi version, however, this example rejects the option string:The user was concerned because his old scripts were breaking when he tried to use them with the MP version, and he had to change to, for example,
Should we try to reproduce ASL's option processing (without spaces) in MP, or should we declare that it was an undocumented feature of ASL that we have chosen not to perpetuate?
The text was updated successfully, but these errors were encountered: