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

[John J Forrest]

Rolf,

CbcModel::setCutoffIncrement(0.1);

John



Rolf Steenge <rolf.steenge at planet.nl> 
Sent by: coin-discuss-bounces at list.coin-or.org
06/06/2006 08:45 AM
Please respond to
Discussions about open source software for Operations Research 
<coin-discuss at list.coin-or.org>


To
"'Discussions about open source software for Operations Research'" 
<coin-discuss at list.coin-or.org>
cc

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






John,
You wrote :
 
"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"
 
How do you set that value of 0.1? Or have you added a constraint such as 
sum of cijxij - 10 xn = 0 with xn a new integer variable.
 
Best regards
Rolf
 
-----Original Message-----
From: coin-discuss-bounces at list.coin-or.org 
[mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of John J Forrest
Sent: Saturday, June 03, 2006 16:02
To: Discussions about open source software for Operations Research
Subject: Re: [Coin-discuss] Suggestions on how to go about tuning?


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_______________________________________________
Coin-discuss mailing list
Coin-discuss at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/coin-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20060607/64ea1e4e/attachment.html>