[Cbc] CBC deterministic

[Sam Mathew]

Hi,

I tried solving an ILP problem with .lp and .mps on the command line with
no threads, but a ratioGap 1e-4. But I get different objective function
value.

Why is there a difference?

Regards,

Sam

On 12 August 2016 at 21:09, John Forrest <john.forrest at fastercoin.com>
wrote:

> Alexis,
>
> As Bjørn wrote, stopping on time is not deterministic.  Otherwise if you
> are not using more than one thread then it should be.
>
> 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.
>
> 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.
>
> If you are using threads try using threads 10n and see if cpu utilization
> is reasonable on your problems.
>
> John Forrest
>
> On 11/08/16 15:57, Alexis wrote:
>
> Hi
>
> 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.
>
> http://list.coin-or.org/pipermail/cbc/2016-February/001891.html
>
> http://list.coin-or.org/pipermail/cbc/2015-January/001580.html
>
> 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
>
> CbcEventHandler::CbcAction myCbcEventHandler::event(CbcEvent whichEvent)
> {
>
> ...
>             if (dIntGapCalc < dIntGapRef)  {
>
>                 ...
>
>                 return stop;
>             }
>
>        ...
>
>   }
>
> ....
>
> }
>
> Thanks in advance
>
>
> --
> Alexis Guigue, E.I.T., B.Eng., M.A.Sc., Ph.D.
> Software Engineer/Research Engineer
> 604-519-6222, ext. 107
>
> Softree Technical Systems Inc. <http://www.softree.com>
> Engineering an Easier Way
>
>
>
> _______________________________________________
> Cbc mailing listCbc at list.coin-or.orghttp://list.coin-or.org/mailman/listinfo/cbc
>
>
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc
>
>


-- 
Senior Process Engineer

*Gyan Data Pvt. Ltd.*
*IITM Research Park*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20160826/11511b95/attachment.html>