<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Noli.<br>
<br>
Let me summarize the situation.<br>
<br>
1. Proximity search is only available in CBC\trunk; in interactive
mode, it is activated by -proximity on. <br>
<br>
2. On stable CBC 2.7.8 the proximity flag is accepted but not used
(yet)<br>
<br>
3. In interactive mode, you can check the LOG to see the effect of
the proximity heuristic, e.g.<br>
<br>
> cbc ..\seymour.lp -proximity on -solve<br>
Welcome to the CBC MILP Solver<br>
Version: <b>Trunk (unstable)</b><br>
Build Date: Nov 29 2012<br>
...<br>
Cbc0012I Integer solution of 428 found by feasibility pump after 0
iterations and 0 nodes (16.67 seconds) <br>
Cbc0012I Integer solution of 427 found by RINS after 0 iterations
and 0 nodes (19.44 seconds) <br>
... <br>
<b>Cbc0012I Integer solution of 426 found by </b><b>Proximity
Search </b><b>after 0 iterations and 0 nodes (37.95
seconds) </b> <br>
...<br>
<br>
4. Proximity search is a refinement heuristic, hence it is NOT
applied when no solution is found at the root<br>
<br>
5. Now I come to your important question below: <br>
<br>
>>> However, I could not understand why 2.7.8 runs faster
than the trunk.
The trunk solved the same MIP double the time (i.e. 2x longer) than
using 2.7.8 with or without the proximity search. It seems that
proximity search does not matter if you run threads (i.e. threads
8).
<br>
<br>
My explanation is that you are just facing "erraticism" here,
meaning that small changes of the initial conditions (including
using a different architecture/compiler/n. of threads) can randomly
change LP sol.s --> branching --> search path, sometimes
allowing you to converge much earlier. <br>
<br>
I recently had a provocative talk about this (well know) behavior,
see Mike Trick's blog at<br>
<br>
<u><a class="moz-txt-link-freetext" href="http://mat.tepper.cmu.edu/blog/?p=1695">http://mat.tepper.cmu.edu/blog/?p=1695</a></u><br>
<br>
Coming to your specific instance (TimberHarvest_0010p.lp), tonight I
ran 99 times cbc\trunk (1-thread) with the command<br>
<br>
> cbc ..\TimberHarvest_0010p.lp -randomCbcSeed 0 -randomSeed 0
-solve <br>
<br>
where -randomCbcSeed and -randomSeed allow you to change the
internal CLP and CBC random seeds (0 uses clock as seed).<br>
<br>
I posted at <br>
<br>
<u><a class="moz-txt-link-abbreviated" href="http://www.dei.unipd.it/~fisch/rand.txt">www.dei.unipd.it/~fisch/rand.txt</a></u><br>
<br>
the LOGs; here is an extract:<br>
<br>
<tt> run CPU sec.s nodes</tt><tt><br>
</tt><tt> --------------------------------</tt><tt><br>
</tt><tt><br>
</tt><tt> #001 422.80 688,438</tt><tt><br>
</tt><tt> #002 120.42 541,641</tt><tt><br>
</tt><tt> #003 289.89 980,125</tt><tt><br>
</tt><tt> #004 442.28 472,552</tt><tt><br>
</tt><tt> #005 599.50 694,749</tt><tt><br>
</tt><tt> #006 638.95 1,192,398</tt><tt><br>
</tt><tt> #007 220.62 464,118</tt><tt><br>
</tt><tt> #008 446.78 581,108</tt><tt><br>
</tt><tt> #009 231.38 627,515</tt><tt><br>
</tt><tt> #010 275.19 714,783</tt><tt><br>
</tt><tt>...</tt><tt><br>
</tt><tt> #069 79.25 262,105</tt><tt><br>
</tt><tt>...</tt><tt><br>
</tt><tt> #099 1816.64 1,998,075</tt><br>
<br>
<br>
So, depending on the random seeds, your instance can be solved in 79
or 1816 sec.s (!!)<br>
<br>
6. Of course, not all instances behave the same, but you better know
that sometimes erraticism can play a relevant role, e.g., when you
make parameter tuning--or when you try to explain why a certain idea
(out of 100 you tried) is working magically well...<br>
<br>
7. In my view, erraticism is an opportunity rather than an
issue--e.g., by running multiple times the same solver with
different random seeds (possibly in parallel), you can hopefully
find better heuristic solutions at the root node. <br>
<br>
Here is an example: running 5 times<br>
<br>
<font color="#000000">> cbc ..\seymour.lp -randomCbcSeed 0
-randomSeed 0 -solve<br>
<br>
produces the following root-node heuristic solutions:<br>
<br>
run #1: Objective value:
429.00000000
<br>
</font><font color="#000000"><font color="#000000">run #2:</font>
Objective value:
428.00000000
<br>
</font><font color="#000000"><font color="#000000">run #3: </font>Objective
value:
426.00000000
<br>
</font><font color="#000000"><font color="#000000">run #4 :</font>Objective
value:
427.00000000
<br>
</font><font color="#000000"><font color="#000000">run #5: </font>Objective
value: 427.00000000 <br>
<br>
Analogously, running<br>
<br>
> cbc ..\seymour.lp -randomCbcSeed 0 -randomSeed 0
-proximity on -passF 0 -solve<br>
<br>
produced (still at the root):
<br>
<br>
</font><font color="#000000"><font color="#000000">run #1:</font>
Objective value: 426.00000000<br>
</font><font color="#000000"><font color="#000000">run #2:</font>
Objective value: 425.00000000<br>
</font><font color="#000000"><font color="#000000">run #3:</font>
Objective value: 425.00000000<br>
</font><font color="#000000"><font color="#000000">run #4:</font>
Objective value: 424.00000000<br>
</font><font color="#000000"><font color="#000000">run #5: </font>Objective
value: 423.00000000 <- optimal value<br>
</font><br>
7. Any comment on the subject is welcome.<br>
<br>
Best<br>
<br>
--Matteo--<br>
<br>
<br>
<br>
<div class="moz-signature">-- <br>
Prof. Matteo Fischetti<br>
DEI, University of Padova<br>
via Gradenigo 6/A<br>
I-35131 Padova (Italy)<br>
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:matteo.fischetti@unipd.it">matteo.fischetti@unipd.it</a><br>
web: <a class="moz-txt-link-abbreviated" href="http://www.dei.unipd.it/~fisch">www.dei.unipd.it/~fisch</a><br>
reports: <a class="moz-txt-link-abbreviated" href="http://www.dei.unipd.it/~fisch/papers">www.dei.unipd.it/~fisch/papers</a><br>
</div>
</body>
</html>