<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><span lang="NO-BOK">Alexis,<br>
<br>
As Bjørn wrote, stopping on time is not deterministic.
Otherwise if you are not using more than one thread then it
should be.<br>
<br>
If you have "-threads 4", then cbc is not deterministic - all
that should be guaranteed is that if you finish the search you
will have a solution with the optimal objective value. This is
because the master thread hands out problems plus current state
to any available thread, and the current state may be slightly
different depending on exact timings.<br>
<br>
If you have "threads 104", then it should be deterministic. In
that case the master hands out what it hopes will be equal
amounts of work to each slave and then waits for all to finish -
and then repeats. For this to work efficiently each slave has
to compute how many "pseudo-seconds" it has taken so far. This
needs accurate estimates as to an iteration on a particular LP -
this needs tedious instrumentation - and most Coin coders don't
do tedious.<br>
<br>
If you are using threads try using threads 10n and see if cpu
utilization is reasonable on your problems.<br>
<br>
John Forrest<br>
<br>
</span>On 11/08/16 15:57, Alexis wrote:<br>
</div>
<blockquote
cite="mid:3f18af2c-a9e9-0ce5-0aa5-3079c935ab5c@softree.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<p>Hi</p>
<p>I am just curious to know how ''deterministic'' CBC is. I know
this question has been raised a few times in this forum i.e.</p>
<p><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://list.coin-or.org/pipermail/cbc/2016-February/001891.html">http://list.coin-or.org/pipermail/cbc/2016-February/001891.html</a></p>
<p><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://list.coin-or.org/pipermail/cbc/2015-January/001580.html">http://list.coin-or.org/pipermail/cbc/2015-January/001580.html</a></p>
<p>I have embedded CBC in my own application. In the case where I
impose an integrality gap (e.g. 20%), I have had my program
stopping and returning with different final optimality gaps
(e.g. 12% and 19%). It is actually a little difficult to
reproduce. I am wondering whether this could come from the fact
that I have (re) implemented the optimality gap stopping
condition (with others actually) in the callback</p>
<p>CbcEventHandler::CbcAction myCbcEventHandler::event(CbcEvent
whichEvent)<br>
{</p>
<p>...<br>
if (dIntGapCalc < dIntGapRef) {</p>
<p> ...</p>
<p> return stop;<br>
}</p>
<p> ...</p>
<p> }</p>
<p>....<br>
</p>
<p>}</p>
<p>Thanks in advance</p>
<p><br>
</p>
<div class="moz-signature">-- <br>
Alexis Guigue, E.I.T., B.Eng., M.A.Sc., Ph.D. <br>
Software Engineer/Research Engineer <br>
604-519-6222, ext. 107 <br>
<br>
<a moz-do-not-send="true" href="http://www.softree.com">Softree
Technical Systems Inc.</a> <br>
Engineering an Easier Way <br>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cbc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>