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

[John Forrest]

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 
> <mailto: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 list
>>     Cbc at list.coin-or.org  <mailto:Cbc at list.coin-or.org>
>>     http://list.coin-or.org/mailman/listinfo/cbc
>
>
>     _______________________________________________
>     Cbc mailing list
>     Cbc at list.coin-or.org <mailto: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/d02a40d3/attachment.html>