[Coin-osi-devel] Re: OsiCbcSolverInterface turn off log messages

[Ted Ralphs]

I'm switching this thread over to here, since it was getting to be a bit 
much for coin-discuss.

Matthew Saltzman wrote:
> 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).

I know this was the way the interface was originally conceived, but 
there's no reason I can see that it *has* to function this way. 
Certainly, none of the commercial solver interfaces function this way, 
and SYMPHONY doesn't either. They all start the IP solve from scratch 
and why not? Unless you've already solved the root LP for some other 
reason, why not just let the solver do it.

I guess I also still don't understand why the brancchAndBound() call in 
the OsiCbc interface can't be exactly the same as the solve call from 
the native interface). What am I missing?

> 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.

Actually, I think you could pretty easily allow CBC to use another LP 
solver, even from within the Clp solver interface class if you wanted. 
SYMPHONY uses a third-party LP solver through a separate Osi interface 
and it is easy to configure. You just have to set the LP solver at 
configure time and the rest is automatic...I don't understand why this 
seems to be causing so much trouble...

>> 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
>>
>>
>>
> 


-- 
Dr. Ted Ralphs
Associate Professor
Industrial and Systems Engineering
Lehigh University
(610)758-4784
tkralphs at lehigh.edu
www.lehigh.edu/~tkr2