svigerske
commented
5 years ago Attachment SLay04H.nl by @svigerske created at 2012-07-20 18:56:52
Open svigerske opened 5 years ago
svigerske
commented
5 years ago Attachment SLay04H.nl by @svigerske created at 2012-07-20 18:56:52
svigerske
commented
5 years ago Comment by @merraksh created at 2012-07-22 14:34:42
First, please note that there is a more robust way to save a solution, which uses the class CouenneRecordBestSol. This is in BonCouenne.cpp at the line:
CouenneRecordBestSol *rs = cp->getRecordBestSol();
I'm not sure whether the lines you added obtain the same effect, but you may want to check the content of *rs first.
Second, I cannot compare the .sol files as they are saved in binary format. The objective function value seems to be correct though: with both stable/0.4 and trunk and using an empty couenne.opt file (apart from the line lp_solver cplex), the version with Cplex finds a solution of value 9859.6599 and that with CLP finds one with value 9859.6596.
One puzzling part is that the debug version, with Cplex, has a false assert: in the trunk version it is due to an integer tolerance missed (whether by a solution returned by the LP solver I don't know), while in the stable/0.4 it is a "basis != __null" assert. When not using the debug version Cplex complains about some contradictory bounds on quite a few variables.
Regards, Pietro
svigerske
commented
5 years ago Comment by @svigerske created at 2012-07-22 15:19:27
I also get the correct optimal value, but the returned solution does not correspond to it.
In my original interface, I also use this CouenneRecordBestSol workaround, but it still gives an incorrect solution point.
Do you get a correct solution when using Couenne with CPLEX?
svigerske
commented
5 years ago Attachment cplex.txt by @merraksh created at 2012-07-23 11:00:15
last line of output when using different LP solvers.
svigerske
commented
5 years ago Comment by @merraksh created at 2012-07-23 11:06:49
I'm attaching the output I get when adding the following two lines right after BonCouenne.cpp:254:
for (int i=0; i < rs -> getCardSol(); ++i)
printf ("[%d %g] ", i, couenneSol [i]);This will print out as the last line of output, and is exactly the same for Cplex and Clp. Note that I also get a couple of Cplex errors as follows:
CPX0000 CPLEX Error 1262: No basis exists.Comment by @svigerske created at 2012-07-23 13:48:51
Hi,
OK, it seems like I can reproduce this.
But why I get a garbage solution from bb.bestSolution(), where bb is a CouenneBab object?
From looking at the code I thought that CouenneBab::bestSolution() has extra been overwritten to take this CouenneRecordBestSol into account:
const double * CouenneBab::bestSolution() const {
if(!problem_ ||
!(problem_ -> getRecordBestSol ()) ||
!(problem_ -> getRecordBestSol () -> getHasSol()) ||
(((fabs (bestObj_) < COUENNE_INFINITY / 1e4) &&
(problem_ -> getRecordBestSol () -> getVal () > bestObj_))))
return bestSolution_;
return problem_ -> getRecordBestSol () -> getSol ();
}It's probably because the solution stored in CouenneBab has the same objective (and thus is not considered worse than the one in CouenneRecordBestSol).
But why the object stores an infeasible point in bestSolution_ at all?
Stefan
svigerske
commented
5 years ago Comment by @merraksh created at 2012-07-25 17:14:13
Cbc and Couenne have different points of access to the problem and its solutions, hence it might happen that Couenne finds a solution that does not get saved in Cbc (this is more likely to happen) or viceversa. This is why solutions are compared at the end, after the branch and bound.
It seems though that bestSolution_ contains an infeasible solution when using OsiCpx, if I understand your query. I have no idea why that happens. Could it be that OsiClp and OsiCpx have different ways to store a solution?
Pietro
Issue created by migration from Trac.
Original creator: @svigerske
Original creation time: 2012-07-20 18:56:36
Assignee: somebody
Version:
Hi,
with the attached instance, Couenne seems to report a wrong optimal solution.
The problem as printed by Couenne (
problem_print_level 3) isI added the lines
in
BonCouenne.cpp:356and withlp_solver cplexI getThus, all continuous variables seem to be at their lower bound, which violates a linear constraint like
(-x_17-x_14-x_11-x_8+x_0) = -0. Only the binary decisions seem to be correct.With CLP as LP solver, I get
Btw, for running with CPLEX, I had to allow a small gap tolerance (e.g., 1%) to have it terminate timely.
I used CPLEX 12.4.
Stefan