The Relationship Between OSI and CBC

The program in Example 2.1 illustrates the dependency of CBC on the OsiSolverInterface class. The constructor of CbcModel takes a pointer to an OsiSolverInterface (i.e., a solver). The CbcModel clones the solver, and uses its own instance of the solver. The CbcModel's solver and the original solver (e.g., solver1) are not in sync unless the user synchronizes them. The user can always access the CbcModel's solver through the model() class. To synchronize the two solvers, explicitly refreshing the original, e.g.,

  solver1 = model.solver();

CbcModel's method solver() returns a pointer to CBC's cloned solver.

For convenience, many of the OSI methods to access problem data have identical method names in CbcModel. (It's just more convenient to type model.getNumCols() rather than model.solver()->getNumCols()). The CbcModel refreshes its solver at certain logical points during the algorithm. At these points, the information from the CbcModel model will match the information from the model.solver(). Elsewhere, the information may vary. For instance, the method CbcModel::bestSolution() will contain the best solution so far, the OSI method getColSolution() may not. In this case, it is safer to use CbcModel::bestSolution().

While all the OSI methods used in minimum.cpp have equivalent methods in CbcModel, there are some OSI methods which do not. For example, if the program produced a lot of undesired output, one might add the line

  model.solver()->setHintParam(OsiDoReducePrint,true,OsiHintTry); 

to reduce the output. There is no setHintParam() method in CbcModel.