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

[mg]

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/caf8bfb6/attachment-0001.html>