[Osi] issue in OsiCbc - corrupting bounds

[Jan-Willem Goossens]

A little late, but anyway:

save/resetToReferenceSolver works, but not nicely: the next solve
("branchAndBound") can take *much* longer to solve, presumably due to
different cut generator settings etc.

For example,

        OsiClpSolverInterface *osiClp = new OsiClpSolverInterface();
	osiClp->readMps("..\\Cgl\\test\\CglTestData\\egout.mps", "");
	OsiCbcSolverInterface *osiCbc = new OsiCbcSolverInterface(osiClp);		
	
	osiCbc->getModelPtr()->saveReferenceSolver();

	osiCbc->branchAndBound();
	std::cout << osiCbc->isProvenOptimal() << std::endl;

	osiCbc->getModelPtr()->resetToReferenceSolver();

	osiCbc->branchAndBound();
	std::cout << osiCbc->isProvenOptimal() << std::endl;

The first branchAndBound takes milliseconds, the second takes about an
hour to solve to optimality.

Regards,

Jan-Willem



On 9 August 2010 23:04, Ted Ralphs <ted at lehigh.edu> wrote:
> Is there any debate over the fact that API functions in OSI should
> have consistent behavior over solvers whenever possible? Yes, there
> have been cases where that's difficult/impossible to enforce for some
> reason related to the implementation of the underlying solver, but in
> my view, solver independence is the most important principle and
> should be enforced in all but the most extreme cases. Otherwise, the
> usability of Osi is reduced significantly. Of course, there is the
> problem of different solvers having different sets of parameters, but
> that is a separate issue really. This particular case seems clear cut.
> The way OsiCbc behaves is inconsistent and I think we should just fix
> it.
>
> As an aside, the problem at the moment with fixing bugs in Osi is that
> the trunk of Osi is incompatible with anything but the trunk of Cbc
> (due to the changes we are implementing in the build tools and the
> reorganization of source code that just occurred in the Osi trunk).
> The trunk of Cbc is in turn incompatible with Dip, among others,
> because those haven't been converted yet. So for a bug fix to be
> useful right now, we would have to propogate it out to the current
> stable and make a new release.
>
> Cheers,
>
> Ted
>
> On Mon, Aug 9, 2010 at 1:11 PM, Lou Hafer <lou at cs.sfu.ca> wrote:
>> Folks,
>>
>>> Anyway, to achieve solver independence it should be OsiCbc's job to
>>> hide [ modification of the problem representation ] from the user:
>>
>>        Presumably this could be done with the saveReferenceSolver /
>> resetToReferenceSolver calls, inside OsiCbc. Matt, how motivated are you? Want
>> to give this a try and see if it works for you? It might be a while before it
>> rises to the top of someone elses' to-do list.
>>
>>        Anyone out there howling that this change will break their code?
>>
>>                                                        Lou
>>
>> _______________________________________________
>> Osi mailing list
>> Osi at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/osi
>>
>
>
>
> --
> Dr. Ted Ralphs
> Associate Professor, Lehigh University
> (610) 628-1280
> ted 'at' lehigh 'dot' edu
> coral.ie.lehigh.edu/~ted
>
>
> _______________________________________________
> Osi mailing list
> Osi at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/osi
>
>