[Cbc] confused about depth

[John Forrest]

James,

Try again with updated trunk.  I think it is connected to previous 
problems.  What I think happened is that the last SOS variable in a set 
is basic and computed as 1.0e-9.  This is taken as non-zero as the 
default SOS tolerance is 1.0e-14.  If the first variable is non-zero 
then it will branch and fix the last variable to 0.0.  However it looks 
feasible to the LP and so the process is repeated.

Anyway see if changes help.

John


On 14/11/2018 00:47, James Howey wrote:
>
> I have a model that occasionally gets lost in the weeds.
>
> Cbc0010I After 6200 nodes, 4814 on tree, 1e+50 best solution, best 
> possible 0 (97.67 seconds)
>
> Cbc0020I Exiting on maximum time
>
> Cbc0005I Partial search - best objective 1e+50 (best possible 0), took 
> 549614 iterations and 6236 nodes (100.02 seconds)
>
> Cbc0035I Maximum depth 4816, 0 variables fixed on reduced cost
>
> My confusion stems from the reported maximum depth of 4816. I have 
> only 270 (sos) objects in the model.
>
> It would seem that by the time I reach 270 I could judge this node 
> integer feasible or not, and continue in shallower depths.
>
> Is this behavior by design, and if, as I suspect, it is, are there 
> situations where this strategy is effective? Maybe even my situation?
>
> Additional info: In my situation, there is an order to the objects 
> that will reliably give you an infeasible/integer solution judgment by 
> the time you reach 270. I have prioritized the objects in this order 
> and turned off strong branching.
>
> What would happen if I hacked the branch decision logic to just  never 
> split the last level? Is branch logic where I will be spending my time 
> in the future?
>
> Thanks for any light you can shed.
>
> jkh
>
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> https://list.coin-or.org/mailman/listinfo/cbc


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20181115/1a366126/attachment.html>