violation: right hand side is violated by 1049.999 about scip HOT 5 OPEN

If it's a numerical issue, then it sometimes helps to set parameter presolving/donotmultaggr = TRUE.
But since the violation is rather large, it could also be a bug, e.g., a wrong presolve reduction.

from scip.

I observed more or less the same issue when solving big multi-commodity flow like (enriched) models using or-tools with scip.
Neither the setting mentioned by Stefan above nor other expected-to-help param-tunings did get rid of the issue.

It may sound harsh, as i never analyzed / debugged it nor did i create upstream issues, but i would warn a bit about this combination (for now).

(The only worklog of mine i can find is my git-msg: "switch away from scip/glop (or-tools) to scip/soplex -> no numerical-trouble issues anymore")

Now the issue here is: where does this come from and "who is to blame" (excuse the wording).

It's not easy to track all relevant actors here. Just a remark from what i understood:

• or-tools with SCIP is using or-tools GLOP and not SOPLEX
  • probably the most important aspect here
    • this implies, that SCIP will use scip/src/lpi/lpi_glop.cpp instead of scip/src/lpi/lpi_spx2.cpp
  • this was my core motivation of using or-tools with SCIP as SOPLEX seems kind of outdated nowadays compared to GLOP/Highs and co.

There are other factors, probably irrelevant, like your binaries missing symmetry-reduction although always active in bazel-based builds (and maybe in cmake-based builds).

Seeing the amount of violation compared to the "smallness" of your problem, it really looks like something rather buggy than a num-tolerance thing (imho). In my case, instances were much much bigger.

I think, i would start with turning off presolve completely and retrying. If still broken, i would claim scip/src/lpi/lpi_glop.cpp is broken.

Maybe you are more helpful than i were and can offer a reproducable test-case for people wanting to analyze it :-). There are probably many paths to achieve that (python code with data; but also protobuf-based serialization which might be accessible through python-wrappers too) howewer.

from scip.

I think, i would start with turning off presolve completely and retrying. If still broken, i would claim scip/src/lpi/lpi_glop.cpp is broken.

that claim would very much be an over-generalization ;)
you have to realize MIP solving is a complex process involving a lot of components, handling numerical inaccuracies that propagate in all components, this is not a simple data processing pipeline. In particular, all solvers have instances on which they return an infeasible solution / detect infeasibility.

There are probably many paths to achieve that (python code with data; but also protobuf-based serialization which might be accessible through python-wrappers too) however.

Overall, the best thing to do is a simple model in MPS / LP format, no need to reinvent the wheel, these are good standards in the MIP community.

from scip.

@quant2008 one thing that can lead to such issues is ill-conditioned problems, typically having very large or very small coefficients. If you can, check if some constraints have these bad numerics.

Do you know if the final obtained solution is indeed valid for your problem or not, checking it with an external program? Or at least checking the optimal value?

from scip.

yes, the final obtained solution is indeed valid. So can I just ignore the violation message?matbesancon

from scip.