I'm running CBC on problems for which not always an integer solution can be found in a given time, so the command line option sec 120 is set (2 minutes maximum). The random seeds are also set to avoid that the same run returns different results (randomCbcSeed 42 randomSeed 42).

However, I found that this still returns non-deterministic results as the the 2min timeout is pretty sensitive to CPU load (~CPU time ~solve time). In fact, I noticed that when running lots of independent CBC runs in parallel (on a CI server which is also shared across other users), this issue is exacerbated. Slower hardware may also return different results than faster hardware which is also a problem for my use case.

Is there any another definitely deterministic way to terminate CBC prematurely so that it always returns the same results (I don't mind if it's a few seconds or minutes more or less than the specified timeout, but stable results are pretty essential for me)?


Use different parameter such as maximum number of nodes to be checked during branching, regardless the time of execution. Hope this helps.

| improve this answer | |
  • $\begingroup$ While I think this is the best solution and I don't know the implementation details of CBC, I guess, one might still get different results on different hardware. $\endgroup$ – T_O May 14 at 16:05
  • $\begingroup$ @Psyndrom Ventura: Do you know if the node inspection time is roughly the same across different problems (i.e. does it always take the same time on the same machine to inspect 1000 nodes for instance)? What I'd like to know is whether I can use this maxN parameter as proxy for the execution time or will one problem instance with maxN 50000 take 10 minutes to solve and another one 20 seconds? $\endgroup$ – orange May 14 at 22:48
  • $\begingroup$ @T_O: why do you think that restricting the number of nodes to inspect is sensitive to the hardware the solver is run on (what does it depend on in your opinion)? $\endgroup$ – orange May 14 at 22:50
  • $\begingroup$ That is not the point. Different hardware can lead to different node selection strategies, different optimal solutions for node LPs, ... Thus it might happen that you find "good" solutions on some hardware quickly (by chance) while on other hardware, you might not find these solutions. $\endgroup$ – T_O May 16 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.