<div dir="ltr"><div>John, thanks a lot for the fast reply :)</div><div><br></div><div><div>Do you think I can still use the 2.9.3 version (release) and just turn gomory cuts off ?</div><div>Does this version (2.9.3) suffer of other known problems that may be worth switching to svn stable ?<br></div><div>(I usually prefer to update to new release versions when possible...) <br></div><div><br></div><div>Thanks,</div><div>Marco</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-24 11:08 GMT+01:00 John Forrest <span dir="ltr"><<a href="mailto:john.forrest@fastercoin.com" target="_blank">john.forrest@fastercoin.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Marco,<br>
<br>
Thanks. I wish I knew why Gomory cuts have started giving
trouble.<br>
<br>
If I run with debug I get<br>
<br>
Cut with 7 coefficients, cuts off known solutions by 1.403e-05,
lo=-1.79769e+308, ub=9.75001<br>
( 3 , -9.75 ) ( 4 , -9.75 ) ( 6 , 9.75001 ) ( 7 , 9.75001 ) ( 8 ,
9.75001 ) ( 9 , 9.75001 ) ( 10 , 9.75001 ) <br>
Non zero solution values are<br>
( 3 , 1 ) ( 4 , 1 ) ( 7 , 1 ) ( 9 , 1 ) ( 10 , 1 ) <br>
<br>
so you can see it is an accuracy problem.<br>
<br>
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.<br>
<br>
So in stable (svn) you now have several options.<br>
<br>
In configure use -DSWAP_GOMORY to use CglGMI as default (you can
still switch back by using gomory ifmove etc.).<br>
<br>
In configure use -DWEAKEN_CUTS=1. This weakens cuts a bit if they
look slightly odd.<br>
<br>
If performance does not suffer, I would suggest first option - or
just change to using -gomory off -gmi ifmove.<br>
<br>
John Forrest<div><div class="h5"><br>
<br>
On 24/03/15 08:23, mg wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hi All,
<div>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)</div>
<div><br>
</div>
<div>It seems related to some wrong cut, since disabling the cut
generators (with cutsonoff off) it works.</div>
<div><br>
</div>
<div>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. </div>
<div>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 ?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks in advance,</div>
<div>Marco</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Cbc mailing list
<a href="mailto:Cbc@list.coin-or.org" target="_blank">Cbc@list.coin-or.org</a>
<a href="http://list.coin-or.org/mailman/listinfo/cbc" target="_blank">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Cbc mailing list<br>
<a href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a><br>
<a href="http://list.coin-or.org/mailman/listinfo/cbc" target="_blank">http://list.coin-or.org/mailman/listinfo/cbc</a><br>
<br></blockquote></div><br></div>