[Cbc] Why unmaintained OsiCbc?

[Ted Ralphs]

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.

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.

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.

Cheers,

Ted

On Sun, Nov 17, 2019 at 5:50 PM Haroldo Gambini Santos <haroldo at ufop.edu.br>
wrote:

> My impression is that OSI interfaces are only well maintained for linear
> programming solvers. Why ?  MIP solvers have much more configuration
> options and OSI 1.0 did not evolve to cope with these things. More
> specifically to OsiCbc,  I think that we don't have anyone working
> actively on it. I think that OSI 2.0 developers are investing now more
> on MIP.
>
> Regarding the use of CbcMain0 and CbcMain1 instead of branch and bound
> of CbcModel:  the performance of the pure branch and bound (without cuts
> and well tuned heuristics) is horrible. A good set of parameter settings
> is maintained in CbcMain0 and CbcMain1  ( the recommended way of calling
> cbc, which includes the same configuration of the standalone command
> line solver).
>
> Cheers
>
> On 17/11/2019 19:10, Jan-Willem Goossens wrote:
> >
> > Hi, a few comment threads discuss how OsiCbc is unmaintained, but I
> > couldn’t understand why?
> >
> > For example,
> > https://github.com/coin-or/CyLP/issues/34#issuecomment-185988123
> >
> > My code (https://github.com/coin-or/SONNET) is also calling solvers
> > via Osi, including OsiCbc. In case of OsiCbc, Sonnet calls CbcSolver
> > to apply some of the ‘special sauce’ mentioned in the comments above.
> >
> > Also, why not use CbcSolver in OsiCbc instead of the plain
> > branchAndBound, like the comment
> >
> > “To enjoy the full performance of Cbc, use the CbcSolver interface.”
> > mentions?
> >
> > Is the best way forward to plan to stop using OsiCbc, or to try to get
> > OsiCbc maintained?
> >
> > Regards,  Jan-Willem
> >
> >
> > _______________________________________________
> > Cbc mailing list
> > Cbc at list.coin-or.org
> > https://list.coin-or.org/mailman/listinfo/cbc
>
> --
> =============================================================
> Haroldo Gambini Santos
> Computing Department
> Universidade Federal de Ouro Preto - UFOP
> email: haroldo at ufop.edu.br
> home/research page: www.decom.ufop.br/haroldo
>
>
> It has long been an axiom of mine that the little things are infinitely
> the most important.
> -- Sir Arthur Conan Doyle, "A Case of Identity"
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> https://list.coin-or.org/mailman/listinfo/cbc
>


-- 
Dr. Ted Ralphs
Professor, Industrial and Systems Engineering
Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20191117/b044987c/attachment.html>