[Cbc] Simple problem found infeasible... but it's not

[mg]

Ok perfect, thanks a lot.

Best Regards,
Marco

2015-03-24 12:24 GMT+01:00 John Forrest <john.forrest at fastercoin.com>:

>  Marco,
>
> Just switch Gomory i.e. -gomory off -gmi ifmove
>
> Will be just the same as next release.  You may wish to make it -gmi root.
>
> John Forrest
>
>
>
> On 24/03/15 11:18, mg wrote:
>
>  John, thanks a lot for the fast reply :)
>
>  Do you think I can still use the 2.9.3 version (release) and just turn
> gomory cuts off ?
> Does this version (2.9.3) suffer of other known problems that may be worth
> switching to svn stable ?
>  (I usually prefer to update to new release versions when possible...)
>
>  Thanks,
> Marco
>
>
> 2015-03-24 11:08 GMT+01:00 John Forrest <john.forrest at fastercoin.com>:
>
>>  Marco,
>>
>> Thanks.  I wish I knew why Gomory cuts have started giving trouble.
>>
>> If I run with debug I get
>>
>> Cut with 7 coefficients, cuts off known solutions by 1.403e-05,
>> lo=-1.79769e+308, ub=9.75001
>> ( 3 , -9.75 ) ( 4 , -9.75 ) ( 6 , 9.75001 ) ( 7 , 9.75001 ) ( 8 , 9.75001
>> ) ( 9 , 9.75001 ) ( 10 , 9.75001 )
>> Non zero solution values are
>> ( 3 , 1 ) ( 4 , 1 ) ( 7 , 1 ) ( 9 , 1 ) ( 10 , 1 )
>>
>> so you can see it is an accuracy problem.
>>
>> Yesterday I had changed stable so that CglGomory cuts were not default,
>> but CglGMI was default - as CglGMI is more stable.  I then decided that was
>> a bit drastic so changed it back unless a Cbc configure option is set.
>>
>> So in stable (svn) you now have several options.
>>
>> In configure use -DSWAP_GOMORY to use CglGMI as default (you can still
>> switch back by using gomory ifmove etc.).
>>
>> In configure use -DWEAKEN_CUTS=1.  This weakens cuts a bit if they look
>> slightly odd.
>>
>> If performance does not suffer, I would suggest first option - or just
>> change to using -gomory off -gmi ifmove.
>>
>> John Forrest
>>
>>
>> On 24/03/15 08:23, mg wrote:
>>
>>  Hi All,
>> I'm currently solving some very small multiknapsack-like problems and I
>> got an infeasibility on the attached problem (CBC version release 2.9.3)
>>
>>  It seems related to some wrong cut, since disabling the cut generators
>> (with cutsonoff off) it works.
>>
>>  I don't know if it's important, but if you look at the attached LP, you
>> can see a constraint called "PrimaryObjAsConstr" that comes from a previous
>> solve where this constraint was actually the objective function.
>> Well, the RHS of this contraint is the objective value of the previous
>> solve (4) plus a tolerance (0.1). If I put it to 4, the model is solved
>> without any problem even with the cut generators enabled. Does this lead to
>> some integer-related stuff ?
>>
>>  For the moment I can solve it by disabling the cut generation, but I
>> wanted to report the issue that might rise again in other cases.
>>
>>  Thanks in advance,
>> Marco
>>
>>
>>  _______________________________________________
>> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20150324/ab1d4e84/attachment.html>