[Osi] How to speed-up flop-osi-cbc ?

Michal Kaut mail at michalkaut.net
Wed Sep 30 04:08:43 EDT 2009


As John points out, using OsiCbc is significantly inferior to using 
CbcMain* routines, used by the stand-alone Cbc solver. Here is a hack I 
am using in my code, including my comments - straight cut&paste from my 
code, no guarantee that the comments make sense..

First definition of the used variables:
- 'model' is a FlopC++ MP_model object
- 'pSolver' is a pointer to OsiCbcSolverInterface attached to model 
(i.e. model->, casted from OsiSolverInterface to OsiCbcSolverInterface)

I have left all the options I am passing to CbcMain in the code 
(including inactive ones), to illustrate how to use it. They work for my 
problem, they might be bad for yours. It is important that 'nCbcArgs' is 
the number of active arguments.

Any ideas for improving it are welcomed.

---------------------------------------------------------------------
/*
According to the mailing lists, using Cbc via OSI is not recommended!
Instead, one should use the Main0 and Main1 function from CbcSolver.
This should work exactly like the command-line cbc solver.
We can even use the same options as we would do for cbc; the default
setup is then invoked by passing the following:
const char *args[] = {"ProblemName", "-solve", "-quit"};

There are two ways of doing this. The first one is quite simple,
we just call the Main0 and Main1 methods directly on the CbcModel
object of the current OsiCbc solver (accessed as *pSolver->getModelPtr(),
since getModelPtr() returns the pointer and CbcMainX needs the object):
CbcMain0(*pSolver->getModelPtr());
CbcMain1(3, args, *pSolver->getModelPtr());
This works, except that it is more than 3x slower than the next solution.

The alternative is to create a new CbcModel from the current OsiClp
solver, accessed from OsiCbc using getRealSolverPtr().
To copy the solution back to the our OsiCbc solver, we simply fix
all the variables to the obtained solution...
(It is possible to copy the solution without fixing the variables, but
  I did not find any way how to update the "best possible" bound - so
  the solver would have the correct solution, but a big optimality gap!)
*/

// set the options we know help with this problem
const int nCbcArgs = 13; // number of arguments sent to CbcMain1()
const char *args[nCbcArgs] = {
   "SSND_Det",        // the name is needed for this to work!
   "-heur", "off",    // switch off all the heuristics
   "-DivingC", "on",  // switch on the "Diving Coefficient" heuristic
   "-cuts", "off",    // switch off all cut generators
   "-gomory", "root", // do Gomory cuts in the root node
   "-mixed", "on",    // do "mixed-integer-rounding cuts" everywhere
   //"-log", "2",       // logLevel for B&B solver (Cbc) (default = 1)
   //"-threads", "2",   // number of threads (default = 0)
   "-solve", "-quit"  // this is obligatory
};
CbcModel model(*(pSolver->getRealSolverPtr()));
CbcMain0(model);
CbcMain1(nCbcArgs, args, model); // this runs the solver

// now fix the variables by changing their bounds
// could use getColSolution() instead of getCbcColLower/Upper
assert (model.getNumCols() == pSolver->getNumCols()
         && "the CbcModel must have the same variables as our solver!");
for (int col = 0; col < model.getNumCols(); col++) {
   pSolver->setColBounds(col, model.getCbcColLower()[col],
                              model.getCbcColUpper()[col]);
}
// in addition, copy the solution basis
// not necessary, but could speed it up (according to Stefan Vigerske)
pSolver->getModelPtr()->setBestSolutionBasis(model.workingBasis());

solve(MINIMIZE); // note that minimize() would call attach again!
---------------------------------------------------------------------

Hope this helps.


As to silencing Cbc, I use
pSolver->getModelPtr()->setLogLevel(0);
again assuming that pSolver is a pointer to OsiCbcSolver interface


Regards,
Michal


John J Forrest wrote:
> 
> Renato,
> 
> I am not sure what -O2 switches on (or off).  If you go into Cbc (or 
> other Coin projects) and just do configure and then look at Makefile, 
> you will see that they tend to use -O3 and stuff like -ffast-math and 
> -fomit-frame-pointer.  You may also want to use -march=native.  If 
> NDEBUG is not defined in your Makefile that would also be a significant 
> hit.
> 
> I very much dislike OsiCbc but if that is what is being used then you 
> may wish to instantiate it with a non-default CbcStrategy object.  This 
> would allow you to have preprocessing which could help.  You can also 
> customize that to use more/different cuts and heuristics.
> 
> The message level for the OsiCbc object could also be modified before 
> handing it to FlopC++.
> 
> John Forrest
> 
> 
> 	
> *[Osi] How to speed-up flop-osi-cbc ?*
> 
> 
> *Renato Bruni * 	to: 	osi 	
> 09/29/2009 02:47 PM
> 
> 
> Sent by: 	*osi-bounces at list.coin-or.org*
> 
> 
> 	
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Hello everybody,
> 
> we are migrating from Cplex to FlpoC++/Osi/(Cbc or Glpk or Symphony).
> We are currently running some tests, but it seems that we need some advice
> to speed-up the open source solvers.
> 
> We are compiling all with gcc with option -O2 (optimization) but it does not
> seem much faster than the debug version. Which options would you recommend
> for speed? Also, we tried to disable messages from the solvers with the
> FlopC++ option "silent", but they write the same messages than before. Which
> other option we can try? Is there some other speed option (cut generation?)
> that maybe is disabled and one should enable? And how? Pointers to some
> documentation are appreciated.
> 
> Thanks a lot in advance.
> Best regards,
> Renato Bruni
> 
> _______________________________________________
> Osi mailing list
> Osi at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/osi
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Osi mailing list
> Osi at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/osi




More information about the Osi mailing list