Differences between objectives in log and sol files in CBC version 2.10.12 (Linux), addition to issue 709

[TR53177]

Again big compliment for CBC, a top solution to tackle solutions that make the world more sustainable (our goal, when using CBC :-)!

To help you a bit more in understanding our issue, we have added a Cplex file, that we have run in CBC version 2.10.8 and 2.10.12 with the corresponding .log and the header of the .sol file for both runs. What we observe is that, at least in the latest version of CBC 2.10.12, the objectives in .sol and .log files are different. Furthermore, the .sol file in this version (2.10.12) does not correspond to the logic in the Cplex.

Of course we know that the the condition "Stopped on time" can cause issues, but at least we perceive that in the newest version (2.10.12) an erroneous / inconsistent sol file is produced, while in older versions the sol file contained a consistent / reasonable sol file that matched the expressions in the lp-file and was equal to the objective in the log file

LP: Question_solfile.lp.txt

Image from header sol-files from running the lp file above in versions:
version 2.10.8 : Header sol-file with objective
version 2.10.12: Header sol-file with objective

log from running the lp file above in versions:
version 2.10.8: log_cbcversion2.10.8.log.txt
version 2.10.12: log_cbcversion2.10.12.log.txt

Header sol-file generated with CBC 2.10.8:

Header sol-file generated with CBC 2.10.12:

log_cbcversion2.10.8.log.txt

log_cbcversion2.10.12.log.txt

Question_solfile.lp.txt

Greetings,
TR

[jjhforrest]

I was unable to reproduce problem with stable 2.10.12. With master I did manage to get it togo wrong. I have tracked that down (and may put in a fix) - it seemed due to tolerance and scaling problems - the code kept on thinking it had a solution and then rejecting it when it looked more closely.

Does this happen if you add -preprocess off? Also does the solution file have infeasibilities i.e. **?

If not then what happens if you input the solution file with -mipstart? Is it feasible and what is objective value?

If it looks as if it is only incorrect objective value then try adding a line to print model_.getObjValue() in CbcSolver.cpp where it says // Write solution header

[PI-31415-PI]

Dear jjhfrorrest,

Thank you for your response. In this particular case it does not happen if I add -preprocess off and indeed in this case I have infeasibilities. But I also have cases where the same thing happens (different objective in solution file and log) where there are no **.

Those cases are more difficult to reproduce, it seems to happen a bit random, maybe due to the time limit something gets broken off too early or so?

The sol file I get from the cases that don't show ** are however infeasible if I fill in the sol file into my constraints. For these cases it does not always help to add -preprocess off.

Attached the lp file and log file

EXAMPLE_LOGFILE.txt
EXAMPLE_LPFILE.lp.txt

[jjhforrest]

It may help to narrow down problem if you can try downloading master and see what happens.

[PI-31415-PI]

Thanks for the suggestion! Unfortunatly it is not possible for me to download master instead of working with a stable version.

[jjhforrest]

How exactly do you build Cbc. I was unable to reproduce error, but maybe my build was subtly different. Does this happen just using one thread?

[jjhforrest]

I have managed to reproduce error. It seems to be something to do with multiple threads. If it does not stop on max time it seems to be okay - and maxnode seems okay. With multiple threads Cbc is not deterministic which makes it a bit more difficult to debug (it can be made deterministic by -threads 112 - and that also seems okay - but not as efficient).
Will look into it.

[PI-31415-PI]

Great, thank you very much for your help!

[jjhforrest]

Answer quite simple. At the end the problem with integers fixed is solved. Normally this takes zero iterations - but can be more. Sometime before 2.10.12 there must have been a very difficult problem where this took too long. So code was added to stop after so many seconds. But the number of seconds had already been reached so the code got confused.

I am not sure it is a totally good idea to stop that way anyway - but definitely not if you have stopped on time already.

I have modified stable.

[PI-31415-PI]

Thank you very much for the fix and explanation! Do you have any idea when you expect version 2.10.13 will be released?