Open timellemeet opened 8 months ago
There are a few scenarios in which HiGHS fails to solve an LP, and these yield "kNotset". My best advice is to solve again with non-default setting of random_seed.
Naturally we're interested to reproduce instances
I'll document something
Check I see! For context: in my use case it is after an iteration of column generation. Depending on the iteration I either only added columns or also als rounding heuristic also add constraints and change column bounds, but the model should never become infeasible. But I am under the impression that this sometimes leads to unexpected behaviour. Especially the moment I first add a constraint suddenly solver run time double. Hard to debug unfortunately. My plan now is to experiment with setting an initial solution myself based on problem knowledge but will try that when the next release of highspy is out.
If the model is infeasible then HiGHS will normally detect it and return kInfeasible. One "failure" comes when the anti-cycling technique stops the basis change that would yield an optimal solution. I've seen a case where failure on resolve (akin to your scenario) is not justified. This reminds me to look into it.
Alright thank you! Aside from solving again with a non-random seed are there any other best practices to do for a "retry" solve. Especially when dealing with making changes to an adjusted model, where by default we continue from the previous solve?
Ultimately you can call clearSolver to force the solver to run from scratch.
Fyi my hypothesis is now that my problem is badly scaled when certain big M columns are added. Inspired by this https://github.com/ERGO-Code/HiGHS/pull/1498. Will verify.
Hi,
Sometimes I experience ModelStatus kNotset after a run. Would be great if we can add to the docs what are scenarios when this is expected behaviour. Maybe in general that part of docs could have a bit more detailed descriptions :).
Thank you!