<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<div></div>
<div>I can make a few PRs to start to use cbcmain in osicbc 'branchandbound' and add libosicbc project back to msvisualstudio v16 folder. </div>
<div>Saves me from keeping track of these changes is my fork :-)</div>
<div><br>
On 18 Nov 2019, at 03:57, Ted Ralphs <<a href="mailto:ted@lehigh.edu">ted@lehigh.edu</a>> wrote:<br>
<br>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div dir="ltr">More configuration options are not a reason to abandon Osi and I find it very unfortunate that no one has tried to make the performance of OsiCbc match the performance of direct calls to Cbc. Cbc is the only solver for which this is the case.
OsiCpx, OsiGrb, etc. all offer the same performance through Osi as through their direct interfaces. I don't think it would be difficult to get OsiCbc up to speed, especially now that there is a C interface! I would like to do it, but there are always just
too many other urgent things on my COIN-OR TODO list.
<div><br>
</div>
<div>It is true that MIP solvers have more configuration options and more options that are specialized to one solver than LP solvers, but configuration options can be easily set for any solver, even if the solver is being called through Osi. For many applications,
though, it is still a huge win to implement using Osi, even if some configuration options need to be set separately on a per-solver basis. </div>
<div><br>
</div>
<div>I have several codes that call Cbc and where using Osi is preferable. If any is interested in taking this on as a small volunteer project, it would be super helpful.</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Ted</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Nov 17, 2019 at 5:50 PM Haroldo Gambini Santos <<a href="mailto:haroldo@ufop.edu.br">haroldo@ufop.edu.br</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My impression is that OSI interfaces are only well maintained for linear <br>
programming solvers. Why ? MIP solvers have much more configuration <br>
options and OSI 1.0 did not evolve to cope with these things. More <br>
specifically to OsiCbc, I think that we don't have anyone working <br>
actively on it. I think that OSI 2.0 developers are investing now more <br>
on MIP.<br>
<br>
Regarding the use of CbcMain0 and CbcMain1 instead of branch and bound <br>
of CbcModel: the performance of the pure branch and bound (without cuts <br>
and well tuned heuristics) is horrible. A good set of parameter settings <br>
is maintained in CbcMain0 and CbcMain1 ( the recommended way of calling <br>
cbc, which includes the same configuration of the standalone command <br>
line solver).<br>
<br>
Cheers<br>
<br>
On 17/11/2019 19:10, Jan-Willem Goossens wrote:<br>
><br>
> Hi, a few comment threads discuss how OsiCbc is unmaintained, but I <br>
> couldn’t understand why?<br>
><br>
> For example, <br>
> <a href="https://github.com/coin-or/CyLP/issues/34#issuecomment-185988123" rel="noreferrer" target="_blank">
https://github.com/coin-or/CyLP/issues/34#issuecomment-185988123</a><br>
><br>
> My code (<a href="https://github.com/coin-or/SONNET" rel="noreferrer" target="_blank">https://github.com/coin-or/SONNET</a>) is also calling solvers
<br>
> via Osi, including OsiCbc. In case of OsiCbc, Sonnet calls CbcSolver <br>
> to apply some of the ‘special sauce’ mentioned in the comments above.<br>
><br>
> Also, why not use CbcSolver in OsiCbc instead of the plain <br>
> branchAndBound, like the comment<br>
><br>
> “To enjoy the full performance of Cbc, use the CbcSolver interface.” <br>
> mentions?<br>
><br>
> Is the best way forward to plan to stop using OsiCbc, or to try to get <br>
> OsiCbc maintained?<br>
><br>
> Regards, Jan-Willem<br>
><br>
><br>
> _______________________________________________<br>
> Cbc mailing list<br>
> <a href="mailto:Cbc@list.coin-or.org" target="_blank">Cbc@list.coin-or.org</a><br>
> <a href="https://list.coin-or.org/mailman/listinfo/cbc" rel="noreferrer" target="_blank">
https://list.coin-or.org/mailman/listinfo/cbc</a><br>
<br>
-- <br>
=============================================================<br>
Haroldo Gambini Santos<br>
Computing Department<br>
Universidade Federal de Ouro Preto - UFOP<br>
email: <a href="mailto:haroldo@ufop.edu.br" target="_blank">haroldo@ufop.edu.br</a><br>
home/research page: <a href="http://www.decom.ufop.br/haroldo" rel="noreferrer" target="_blank">
www.decom.ufop.br/haroldo</a><br>
<br>
<br>
It has long been an axiom of mine that the little things are infinitely<br>
the most important.<br>
-- Sir Arthur Conan Doyle, "A Case of Identity"<br>
<br>
_______________________________________________<br>
Cbc mailing list<br>
<a href="mailto:Cbc@list.coin-or.org" target="_blank">Cbc@list.coin-or.org</a><br>
<a href="https://list.coin-or.org/mailman/listinfo/cbc" rel="noreferrer" target="_blank">https://list.coin-or.org/mailman/listinfo/cbc</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">Dr. Ted Ralphs<br>
Professor, Industrial and Systems Engineering<br>
Lehigh University<br>
(610) 628-1280<br>
ted 'at' lehigh 'dot' edu<br>
<a href="http://coral.ie.lehigh.edu/~ted" target="_blank">coral.ie.lehigh.edu/~ted</a><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>