[Coin-discuss] Suggestions on how to go about tuning?

[Darla and Philip Walton]

John,
Here is what I learned/further questions:
- If I knew something about "symmetry breaking" I should probably give it a 
go at coding it up and contributing it.
- Yeah, I should have mentioned....all variables are BV, but because of the 
formulation, I've only specified a subset as BV.  In early tests this shrank 
the B&B tree size....The integer ones will force the others to integer. 
Apparently I crippled strong branching by doing so.  In the end, was leaving 
them BV the faster choice?  On a hunch you turned it back off.  What does 
the number in setNumberStrong() mean?  0=off? 5 = magic #?  .... how do I 
pick a good one?  Did I just plain miss some doc somewhere?
- I'm not sure exactly what "strong branching" means.  I don't remember that 
one...gettin' old...the cob webs are encroaching.
- So... you set something like "min improvement" to .1?  although that is 
luck of the draw with this particular data set, it could happen in practice 
very frequently... what precisely did you do there... I know the concept, 
but not where to find the knob to twist.

BTW, in the driver I sent you without any thing else, it actually gets the 
optimal solution almost right out of the gate.  The cuts it adds are good. 
It takes a longer time to prove it, but it finds it quickly.

This doesn't happen without the call to initialSolve.  So it gets the 
absolute best upper bound very fast.  It sounds like the real winner here 
was setting the .1 min increase...

Thanks for your time and effort.  I do appreciate what it takes.  BTW, I'm 
thinking of making it to Rutgers in July.  I hope to put a face with the 
name.

Cheers!
Philip
[snip]
> Philip,
>
> I said I would play about with your problem and report on what I did and
> how I went about it :
>
> All these experiments were with stand alone solver - SOS is a bit trickier
> and I will get to that later.  Also symmetry breaking would help but I
> would need help in CglPreProcess and/or pointers to relevant papers.
>
> The first thing to do is solve the problem however slowly and look at log
> and solution.  Using defaults this took 1148 seconds and 150K nodes.
> Looking at the log file it looked as if strong branching was not buying
> very much.  What was more interesting was that all variables took integer
> values although only half were declared integer.  Assuming this would
> always be true I tried setting them all integer.  This time strong
> branching was kicking in and it took 5K nodes and 413 seconds.  I also saw
> that cuts and heuristics were not doing much good so switched them off.
>
> Again looking at log I saw that Cbc could work out that valid objective
> values had to be a multiple of 0.1 so any solution has to be 0.1 better
> than previous.  Going back to original formulation and setting that value
> of 0.1 gave  31K nodes but 305 seconds.  Finally in this phase of tuning I
> tried switching off strong branching as my hunch was that it might cost
> too much for the effect gave an increase in nodes to 38K but the time
> dropped to 233 seconds.
>
> Further ideas such as just having some (but not the original set)
> variables integer gave various perturbations on time and nodes but no
> significant improvement.
>
> I have started looking at SOS possibilities but am not far along.
>
> Basically I use multiple runs and an editor and grep to try and get a feel
> for problem.
>
> John Forrest