[Coin-discuss] OSI semantics: basis maintenance, model modification

[Lou Hafer]

Folks,

	I've gotten sbb working with dylp without cuts, and have moved on to
getting cuts working. I've run into an issue that turns on the semantics of
methods in OsiSolverInterface.

	Generalized, it amounts to this: Should an OSI automatically maintain
a basis in the face of changes to the constraint system? OsiClp certainly
does this, in calls to [add|delete][Row|Column](). OsiDylp currently does
not. There are some arguments for and against.

	An argument for pushing basis maintenance into OSI is simplification
of client code (like branch & cut) that repeatedly modifies and resolves a
problem.

	An argument against is that this is perilously close to maintaining a
solution in the face of changes to the constraint system, which (if I
correctly recall a previous discussion) the OSI is not supposed to do.
Deletion (directly or indirectly) of a basic variable could be painful.

	Taken to its logical end, basis maintenance would start as soon as
the first constraint is added. A compromise position would be to insist that
a basis be maintained after the first call to initialSolve(), and invalidated
by a bulk load of a new constraint system (readMps() or similar).

	Sbb contains examples of both styles of basis manipulation. Contrast
SbbModel::addCuts, which explicitly compresses a basis using
OsiWarmStartBasis calls to modify and set the basis, vs.
SbbModel::takeOffCuts, which counts on OSI::deleteRows to handle it.  Both
chunks of code scan a basis for loose cuts and leave the OSI holding a basis
with the loose cuts removed. (There are good reasons for the difference in
styles, but they're not particularly important here. The two pieces of code
are reasonable examples of each style.)

	Thoughts? What's the majority opinion among OSI implementors? 

					Lou