OsiCbc is unmaintained?

[spoorendonk]

According to documentation and in-program messages the interface is deprecated. Not pointing fingers just looking for insight.

Is it reported anywhere what is missing? Any plans to get this up to speed to be able to swap solvers? Is Osi2 taking over?

[tkralphs]

There has long been a "plan" (I am interested in seeing this happen for the same reason you are @spoorendonk), just hasn't happened yet. There is a thread about it here and there is also #277. Maybe @jhmgoossens can give us an update?

[jhmgoossens]

The update is: I haven't found (made) time.. The point made in the email thread is that in OsiCbc the current branchAndBound doesnt use automatic cuts etc. that are offered via the CbcSolver API for example--only manual via CbcStrategy. As a consequence, out of the box the branchAndBound of OsiCbc has very poor performance to the point where it's pointless to keep the original OsiCbc around.

In the mail thread I was hoping it would be easy to replace the code in branchAndBound with a few lines of calls to CbcSolver. But It's not that simple, especially if we want to keep the original OsiCbc functions around (with basic branchAndBound, CbcStrategy, etc.). But keeping the old and new functionality seems artificial and unnecessary. The alternative is to rip much of the OsiCbc code out and replace with the parts only possible when using CbcSolver. But here even things like setIntParam are (I think) not straightforward through CbcSolver. I'd love to hear that it's actually not so difficult :-) (Note, what I do in Sonnet code is use OsiCbc for everything except branchAndBound. For solving I pass to CbcSolver.)

[tkralphs]

I don't really see any reason to keep around the old functionality. If one really wants to directly call branchAndBound() with a blank slate, this can easily be done by accessing the model pointer directly. It looks like jut replacing the call to branchAndBound() with something like what is in the C interface should be sufficient for started. Setting parameters also looks pretty straightforward through the cbcModel object. But I could be overlooking something.

[jhmgoossens]

Well, settings parameters using the underlying cbcModel is easy but having CbcSolver obey to these parameter values?

[tkralphs]

Unless I'm missing something, I don't anticipate any problems with that. The cbcModel object is what gets passed in when solving, so the parameters settings should also get passed in.

[spoorendonk]

It looks like jut replacing the call to branchAndBound() with something like what is in the C interface should be sufficient for started.

Related to #310 I guess. If the CbcSolver get's up to speed then OsiCbc could be a thin wrapper on that.

[jhmgoossens]

Coming back to this topic, is it as simple as below to get OsiCbc started with basic support to use CbcMain0/1? Or is this somehow Much More Complicated?

#include "CbcSolver.hpp"

// Invoke solver's built-in enumeration algorithm
void OsiCbcSolverInterface::branchAndBound()
{
  //if( messageHandler()->logLevel() > 0 ) {
  //  *messageHandler() << "Warning: Use of OsiCbc is deprecated." << CoinMessageEol;
  //  *messageHandler() << "To enjoy the full performance of Cbc, use the CbcSolver interface." << CoinMessageEol;
  //}
  //modelPtr_->branchAndBound();

  CbcSolverUsefulData cbcData;
  CbcMain0(*modelPtr_, cbcData);
  const char* argv[] = { "OsiCbc", "-solve", "-quit" };
  CbcMain1(3, argv, *modelPtr_, cbcData);
}

[tkralphs]

It looks that way to me. I was planning to circle back to this after (hopefully) completing the refactoring of Cbc, which would make this even cleaner.