[Coin-osi-devel] [Coin-discuss] Glpk Osi for interior point?

[Lou Hafer]

Michal, et al.,

        This thread about access to glpk's interior point solver goes to the
core of one of the problems with the current OSI:  At over 150 methods and
growing, the API still has trouble working with anything other than a
simplex-based solver.  I've always been of the opinion that including
branchAndBound in the OSI API was a mistake.  I think a few more OSI
developers (not all, by any means :-) are coming around to that opinion. It
raised expectations in the user community that ultimately cannot be satisfied.
 
        I'll second Matt's suggestion (or perhaps take it a step further): A
very interesting experiment would be an OsiInteriorSolverInterface *base*
class, developed with the primary goal of being a good interface to an
interior point solver.  Compatibility with the existing OsiSolverInterface
would be a secondary goal. From that, derive OsiGlpkInteriorSolverInterface.
(We really have to do something about name length ... ) As Matt says, the
idea of the experiment would be to see what routines should be common across
different solver classes, and what routines are unique to interior point
solvers.  One could envision the same thing for an underlying MIP solver,
with an OsiMIPSolverInterface base class. Et cetera.

        To make this specific: Each of the three classes would most likely
have an initialSolve() and resolve(), but they might look very different in
the implementations.
 
        Michal also mentions that attempting to warm start the glpk simplex
solver from the interior point solution using setColSolution does not work.
This is generally true: set[Row,Col]Solution is not required to talk to the
solver, and an OSI can simply hold this information in the OSI object.

        As others have pointed out, to warm start a simplex solver you need a
basis. OSI will not invent one; you need to supply a CoinWarmStartBasis
object.  Arguably, a `derive warm start from row and column solution'
capability would be a nice extension to OSI.  In the absence of such an
extension, the CoinWarmStart hierarchy and [set,get]WarmStart are the
relevant code to impose a solution on the underlying solver.

        To turn this back to the notion of OsiInteriorSolverInterface, it
would also be appropriate to extend the CoinWarmStart hierarchy with
something appropriate for an interior point code.

    							Lou