Closed andreaslundell closed 4 years ago
There is one fix in Cbc stable/2.10 since 2.10.4 that had to do with the result when Clp ran into the timelimit: https://github.com/coin-or/Cbc/commit/4590be2c465cbd1229873f37afece9d62c7a327e Can you try whether this helps regarding the solution status?
The run from SHOT has the line Option for nodeStrategy changed from hybrid to fewest
, while the standalone Cbc doesn't, but seems to run feasibility pump. I don't know at the moment why that happens.
Yes, using that fix seems to work. Thanks!
Regarding the different behavior from Cbc called by SHOT and Cbc called alone, I believe I found the cause. SHOT calls
CbcMain0(model);
CbcMain1(nargs, args, model);
CbcMain0 is https://github.com/coin-or/Cbc/blob/3b94d71b94520d41e065104ebf4c87af4a2b1f3c/Cbc/src/CbcSolver.cpp#L10641-L10650
So it creates an object solverData
and calls the other CbcMain0 routine with it. That other routine changes a lot of parameters in solverData
. Then the first CbcMain0 frees solverData
again. So CbcMain0(model)
doesn't seem to make much sense.
This change in SHOT seems to bring it closer to what the Cbc executable is doing:
--- a/src/MIPSolver/MIPSolverCbc.cpp
+++ b/src/MIPSolver/MIPSolverCbc.cpp
@@ -483,15 +483,13 @@ E_ProblemSolutionStatus MIPSolverCbc::solveProblem()
env->output->outputError(" Error when adding MIP start to Cbc", e.what());
}
- CbcMain0(*cbcModel);
-
if(!env->settings->getSetting<bool>("Console.DualSolver.Show", "Output"))
{
cbcModel->setLogLevel(0);
osiInterface->setHintParam(OsiDoReducePrint, false, OsiHintTry);
}
- CbcMain1(numArguments, const_cast<const char**>(argv), *cbcModel);
+ CbcMain(numArguments, const_cast<const char**>(argv), *cbcModel);
MIPSolutionStatus = getSolutionStatus();
}
Unfortunately, turning off Cbc output doesn't work this way, because noPrinting is hardcoded to false: https://github.com/coin-or/Cbc/blob/3b94d71b94520d41e065104ebf4c87af4a2b1f3c/Cbc/src/CbcSolver.cpp#L10632-L10639 But I guess you could just copy do a
CbcSolverUsefulData cbcData;
CbcMain0(*cbcModel, cbcData);
CbcMain1(numArguments, const_cast<const char**>(argv), *cbcModel, dummyCallBack, cbcData);
in SHOT, where dummyCallBack
is
static int dummyCallBack(CbcModel * /*model*/, int /*whereFrom*/) { return 0; }
And I'll have to fixup the GAMS/Cbc interface.
When solving e.g.
autocorr_bern25-13
from MINLPLib, which SHOT can reformulate into an MILP problem, Cbc has some strange behavior.If calling SHOT with
--mip=cbc --timelimit=70 Dual.Relaxation.Use=false Subsolver.Cbc.DeterministicParallelMode=true --threads=1 --debug
(on the stability branch), the first and only SHOT iteration produces the following output:So although it has found an integer solution, it claims the problem is infeasible. Also the return status should not be infeasible, but that a time limit has occured.
Well if I then run it with standalone Cbc (and the LP-file produced by Cbc in the same run), I get the following output:
I do not know if there is something wrong in the Cbc call by SHOT or a bug in Cbc, but there seems to be different behavior when calling Cbc directly. The return status is correct in this case, and the solution is reported. There also seems to be a lot more output lines written to screen when calling Cbc directly.
Can you verify this @svigerske? And do you have any suggestions, or do you believe this is a bug in Cbc?