failing assert at MIPSolverCbc.cpp:1464 about shot HOT 9 CLOSED

No, my version of SHOT with Cbc seems to solve this problem fine... Can you see the value of varIndex?

from shot.

varIndex is 1.

osiInterface->getColLower()[varIndex] is -1.79769e+308, so that seems to be some mismatch about what is -infinity.

from shot.

#76 should fix this as well I assume. Can you verify @svigerske?

from shot.

No, I still get that one.

from shot.

Hmm... Cannot still reproduce this, but the asserts are there for a reason, because I noticed there was some issues with Cbc not saving the variable limits.

Can you try to set Model.Variables.Continuous.MaximumUpperBound=1e+10 and Model.Variables.Continuous.MinimumLowerBound=-1e+10 and see if that helps. I believe the "infinity" value in Cbc is 1e+50, which is set here, but perhaps that has changed.

from shot.

Yes, that makes the assert go away.
So that means that if SHOT sets the lower bound to -1e10, then Cbc accepts and keeps it, probably assuming that this really means -1e10 and is not just some proxy for -infinity.
But if one passes on -1e50, then Cbc turns this into a -1e308 (actually COIN_DBL_MAX = (std::numeric_limits< double >::max)()).

This is where Clp changes everything below -1e27 to -COIN_DBL_MAX:

https://github.com/coin-or/Clp/blob/134c3360ce71a54ed8ce9fdc68d3393f0897e383/Clp/src/ClpModel.cpp#L592-L604

There is this line in MIPSolverCbc.cpp, which may then use a wrong constant:

double MIPSolverCbc::getUnboundedVariableBoundValue() { return 1e50; }

If I change this to 1e27, things also work. I guess that's the same reason why setting the parameter to 1e10 worked - it's still a finite bound for Cbc. But I suspect that this means that when there is an unbounded variable in SHOT, then it will have a very large finite bound for the MIP solver?

from shot.

Yes, the same is true for Gurobi and Cplex as well afaik: infinity is 1e+20. So perhaps I will change this into

double MIPSolverCbc::getUnboundedVariableBoundValue() { return 1e27; }

(or should it rather be 1e26 since there is strict inequality in the Clp code?).

from shot.

1e26 or 1e27 doesn't really matter. For both values, the solver will assume that the variable has a finite bound. If you want Cbc to handle the variable as unbounded, then you need to set it to something above 1e27.

Setting it to COIN_DBL_MAX would help to avoid the assert for unbounded variables, but Cbc will then set any (finite) bound above 1e27 to COIN_DBL_MAX.

Setting it to nextafter(1e27, DBL_MAX) could make sense. But one would still need to adapt the assert to allow that if a Cbc bound is set to nextafter(1e27, DBL_MAX), then it will internally be changed to COIN_DBL_MAX.

from shot.

When I'm thinking about it everything except the assert works well now. I am afraid that if I change the logic behind this things might break down (for example, with regards to the infeasibility repair, unbounded MIP iterations, etc.). I think I will disable the assert for now, close this issue and create a new issue to look into changing the Cbc max variable bound to 1e27.

from shot.