ERGO-Code / HiGHS

Linear optimization software
MIT License
962 stars 179 forks source link

Look into resetting anti-cycling technique when resolving #1607

Open timellemeet opened 8 months ago

timellemeet commented 8 months ago

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!

jajhall commented 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

timellemeet commented 8 months ago

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.

jajhall commented 8 months ago

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.

timellemeet commented 8 months ago

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?

jajhall commented 8 months ago

Ultimately you can call clearSolver to force the solver to run from scratch.

1598 will yield another option

timellemeet commented 8 months ago

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.