Can you make Cbc run faster on your problem?

[jjhforrest]

There was a comment recently that the current master was slower on a user's problem than an older release. Ted Ralphs pointed out that there can be many reasons for one particular problem being slower. I thought it might be useful to share thoughts on this. In particular, I would like to suggest some options which users might wish to try. Also if anyone wishes to submit a problem, I will be happy to suggest options that help. Otherwise we can look at the simplest test set which can be investigated by running "cbc -dirmiplib /xx/miplib3 -unittest

To start with there are compile time options that might help. If just compile Cbc with no special options and run that test it takes 2minutes 12 seconds (marginally more cpu time). If I compile with the options I prefer - mainly to allow symmetry breaking and use a simpler dense factorization, this comes down ten seconds.

More importantly some options may improve your running times. Cbc normally uses Clp and can just say "resolve" at each node. This should give the smallest number of nodes - but does incur startup costs for each solve as it keeps on going in and out of Clp. The default tells the code (at depths > nn in tree) to try and do a complete depth first search. This is much faster per node but less efficient. This was the option that gave 2 minutes 12 seconds. Doing "resolve" at each node took 2 minutes 40 seconds. However a third option has been improved in master. This stays in Clp for some nodes and then returns a set of new descendant nodes. This still normally takes more nodes, but not as many as the default option. With this the time goes down to 1 minute 55 seconds. This is switched on by -depth +nn (if 1 code guesses a depth). There are other options I use - some of which I can not totally justify - except they give good times on this test set. So with all options the time is 1 minute 35. With the compile options I like the time is 1 minute 5 seconds!

The point of this long boring post is to allow users to look into ways of improving their run times. Other areas are different cut generators and different heuristics to get good solutions early.