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`.