[Coin-discuss] OsiCbcSolverInterface turn off log messages

[Matthew Saltzman]

On Fri, 9 Mar 2007, Tim Hultberg wrote:

> Yes, but even though I am interfacing with the abstract Osi interface in
> flopc++, a user must still choose a concrete solver and can set solver
> specific hints via Osi. As for example
>
> MP_model m(new OsiCpxSolverInterface);
> m->setIntParam(OsiMaxNumIteration,2); //or whatever
>
> If I understood John correctly, the problem with OsiCbc is that it 
> delegates the methods to the underlying LP solver which is not 
> necessarily Clp and might even be unknown to the application. Therefore 
> I support your proposal to let OsiClp:brachAndBound() invoke Cbc (with 
> Clp as underlying LP solver)

The important thing here is to be able to warm-start Cbc with the optimal 
solution to the LP.  For the solvers with built-in B&B, calling 
branchAndBound() starts with the solution to the root LP and can branch 
immediately.  If you can't initialize the CbcSolverInterface with the LP 
optimum from CLP, then invoking CBC from scratch isn't going to work too 
well.  OsiClp::branchAndBound() would need to handle this transparently in 
order to preserve some semblance of solver independence.  I'm guessing 
that would mean cloning the OsiClpSolverInterface object as an 
OsiCbcSolverInterface object, setting the optimal LP solution, and 
starting CBC off with it.  Even this way, CBC would probably still need to 
refactor (but that's probably not too onerous).

The other issue is whether you really want to force the use of CLP as the 
LP solver whenever you use CBC as the IP solver through OSI.  What a 
full-fledged CbcSolverInterface would give you is access through Cbc calls 
to whatever LP solver you have CBC using.

>
> Tim
>
>>>> Ted Ralphs <tkralphs at lehigh.edu> 03/09/07 7:22 PM >>>
> But this is the case for all solvers when called through Osi. The Osi is
> basically for users who are willing to give up a little flexibility in
> how they interact with the underlying solver in order to have a standard
> API and the ability to switch solvers easily. Even notwithstanding the
> more limited interface, any code written to work with multiple solvers
> is going to suffer some loss of performance. Most users just want to run
> with defaults and will find this tradeoff worthwhile. If someone really
> wants to fine-tune the solver and performance is absolutely paramount,
> OSI may not be a good choice.
>
> Ted
>
> John J Forrest wrote:
>>
>> The reason I dislike OsiCbc is that it uses other OsiXxx solvers so
>> there is no clean structure.  If you do
>> OsiCbcSolverInterface::branchAndBound it calls Cbc's branch and bound
>> which uses a OsiXxxSolverInterface solver.  To make things even worse
>> this underlying solver could be OsiCbcSolverInterface!! (eventually a
>> real solver would be called).
>>
>> Also it is difficult to tune as apart from CbcStrategy it only has
>> OsiXxxSolverInterface methods.
>>
>> The status of OsiCbc will always be - it will work - but it will not
>> easily take advantage of new ideas in Cbc or tuning parameters.
>>
>> John Forrest
>
>
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs