[Osi] Proper way to fix Integers after a branchAndBound call?

[Sylvain R]

After digging into OsiCpxSolverInterface.cpp, I happened to find where the problem was:
I had a bug in my "fixIntegerVariables()" method... which was not only fixing Integer and Binary variables... but was also fixing all the Continuous variables! With a problem with 100% of the variables fixed... no wonder I was getting 0 for all my constraint's shadow cost.
Thanks a lot for your help and taking the time to answer! 
At least I confirmed in the first place that my approach was valid (as I did not find much documentation on that particular problem).

Sylvain

> Date: Tue, 29 Nov 2011 08:45:03 -0800
> From: lou at cs.sfu.ca
> To: osi at list.coin-or.org
> Subject: Re: [Osi] Proper way to fix Integers after a branchAndBound call?
> 
> Sylvain,
> 
> > I am trying to solve a MIP problem and get the shadow costs of the
> > constraints after that. Out of the box that does not work if I just
> > call si.branchAndBound() and then si.getRowPrice(), which makes
> > sense. So this is what I did: 1. call si.branchAndBound();2. check
> > that it is proven optimal.3. loop through all the Integer/Binary
> > variables and set their Upper and Lower bounds to the solution found
> > during branchAndBound().4. call si.resolve(); Note that I am using
> > CPLEX as the solver's backend. The problem I am facing is that the
> > vector returned by si.getRowPrice() is only zeros. I figured that by
> > removing step #3 from my code, and just calling resolve(), I get
> > non-zeros values out of getRowPrice(), and they look descent. But
> > then my Integer variables becomes not Integer anymore...
> 
> To add a bit to Stefan's explanation: The branchAndBound() call is
> regarded by some of us (myself included) as a mistake that should never
> have been included in the OSI API. OSI is a good match for continuous
> exterior-point LP algorithms (i.e., simplex). It copes with various
> other continuous LP algorithms. It simply doesn't have the hooks for
> anything more complicated. To my knowledge, for the OsiXxx that
> implement branchAndBound(), it'll be a standalone call to the underlying
> solver. Integrality conditions (bounds) are not propagated back to the
> problem representation held in the OsiXxx object. Other values (duals,
> for example) are not in general valid. That's why you need step 3 to
> impose integral bounds on the problem representation held in the OsiXxx
> object before calling resolve(), which is a continuous resolve. After
> that, the OsiXxx data structures are valid.
> 
> It's an ongoing debate.
> 
> 						Lou
> _______________________________________________
> Osi mailing list
> Osi at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/osi
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/osi/attachments/20111130/d9ef1bc9/attachment.html>