[Coin-discuss] How to choose a MIP solver in GLPK OSI?

[Kendall Bailey]

I initiated the thread referred to in 2006.  I still believe that the
Osi interface should allow client code to push arbitrary parameters
into a solver and test for success of failure.  The point that I made
before is that the setXXXparams methods already can return a failure,
so well written code must already deal with the possibility that a
particular solver rejects a parameter.

Say I have a Python extension module which can dynamically load any
Osi solver library.  Then someone releases a new OsiSuperMIP library
with new parameter that the base Osi interface knows nothing about.  I
will be able to plug the OsiSuperMIP solver into Python without
modifying the extension module and recompiling.  But none of my
scripts can take advantage of the new parameters.  I can't downcast
inside a Python script.  The Python extension module (written in C++)
knows nothing of the methods unique to OsiSuperMIP.

But if there were a way to pass any tagged int, double or string into
the Osi interface, then the Python extension module would expose that,
and throw a runtime exception if the concrete solver being used
rejects any given parameter.  Now I can tweak my scripts to set all
the OsiSuperMIP parameters I like and never need to break out a C++
compiler.

Someone suggested I implement a map<> of parameters in the
OsiSolverInterface.  That's not needed.  The default implementation of
setOtherXXXParam() is to just fail.  Individual Osi solver wrappers
would override and accept whatever params they can implement.  It
would be nice to have a common namespace for parameters that are
accepted by more than one solver, but not critical.

My effort was to plug any Osi solver into AMPL.  The AMPL program can
pass arbitrary parameters to the solver via environment variables.  It
makes sense to me to just try to pass those right on through.  But
without a generic API, the AMPL driver needs apriori knowledge of each
solver's possible options so it can downcast when needed and push the
parameters in a solver custom way.


Kendall

On 6/22/07, Tim Hultberg <Tim.Hultberg at eumetsat.int> wrote:
> You can downcast to a specific osi solver interface from flopc++ like
> this:
>
> "This is the (not very sexy) way to set the relative termination
> tolerance in Flopc++/CBC
> dynamic_cast<OsiCbcSolverInterface
> *>(MP_model::getDefaultModel().operator->())->getModelPtr()->setAllowableGap(0.1);"
>
> Tim
>
> >>> Michal Kaut <mail at michalkaut.net> 18/06/2007 11:56 >>>
> Hello,
>
> I have a MIP problem that GlpSol with "--intopt" solves in 0.2 seconds,
>
> but won't solve at all without the option  (I let it run over the
> weekend, it did not even find a feasible solution...)
>
> Unfortunately, using GLPK OSI uses the old/original lpx_integer()
> method, which is equivalent to running glpsol without parameters - and
>
> hence useless for my problem.
> Is there a way (in OSI) to use lpx_intopt() instead of lpx_integer(),
> other than rewriting OsiGlpkSolverInterface::branchAndBound() and
> re-compiling OSI?
>
> I found a discussion on coin-osi-devel from March 2006:
> http://list.coin-or.org/pipermail/coin-osi-devel/2006-March/000002.html
>
> Has anything changed since then? I really believe that it is important
>
> that OSI has some (preferably simple-to-use) interface to
> solver-specific options.
>
> Note: In the discussion, they mention downcasting/direct call of the
> GLPK function. Would it work also from FlopCpp? If so, could someone
> show me how?
>
>
> Thanks a lot in advance.
>
>
> Regards,
> Michal Kaut
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>