[Coin-lpsolver] OsiSimplexInterface behaviour

[Lou Hafer]

> > (Lou)
> >
> >  << Context is behaviour of solvers when OsiSimplexInterface is enabled.
> >     Question (broadly) is the effect/implications of asking a solver to
> >     perform a pivot sequence that might normally be considered a violation
> >     of the rules for the current simplex phase. >>
> >
> > 	Does a solver really need to be `in a phase' at all times? Well, no,
> > not really. The various checks (in dylp, at least) really are sanity checks.
> > Given a phase, you can assume certain things shouldn't happen. That allows
> > some simplifications in the code. Violations are normally a good indication
> > of a coding error. So being in a phase serves a useful purpose.
> >
> > 	Now I've written that last paragraph, I guess I'd say the real problem
> > is that dylp assumes that if it's doing simplex pivots, then it's in one of
> > primal I, primal II, or dual II. It probably wouldn't be too difficult to 
add
> > a `no phase' phase (:-) to various specific routines (pivot, factorization).
>
> (Mikhail)
> 
> OK. But then it probably makes sense to have a "richer" enabling routine
> in OsiSimplexInterface. We should have at least three modes: primal, dual
> and "neither". There is also an issue of what OsiSolverInterface calls
> would be allowed in either of these modes. E.g., would adding a row while
> in "primal" or "column" while in "dual" be allowed? How about changing
> objective coefficients, right-hand-side, bounds? Can resolve() be called?
> I though it would be reasonable to, at least, be able to call resolve().
> Etc, etc, ...

	dylp could likely cope with chunks of this --- addition/deletion of
	rows & columns is native. Some nontrivial interface work would be
	required. Efficiency could be an issue where the basis inverse is
	augmented. The math is straightforward, but I'd have to have a hard
	look at Makhorin's basis package to see how an incremental update
	would be handled. Might be worth it. For dylp would be the potential
	for efficiency gains in other places.
	
> > 	What sort of behaviour would be expected at the transition back to
> > solver control? Would the solver be allowed to assess it's state and proceed
> > accordingly?
> 
> What does transition mean? If it is a call to resolve(), should not
> solver state assessment happen automatically?

	That's the answer I was hoping for.
	
	I'll have to go back and dig up the original emails and docs on
	OsiSimplexInterface and have a hard look. And give and mark a final.
	I'll dive back into this once marking is done.
	
							Lou