<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Just to follow up, the issues were caused by a combination of SYMPHONY not properly saving and re-loading the basis during strong branching and some minor bugs in Clp. John put in fixes for the Clp issue and everything seems to be good now (with respect to both issues, which seem to have been related). Here is his description of the issues:</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">When Clp stops on maximum iterations (not hot start) there were several problems -</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">a) OsiClp had "crunched" down the problem - on maximum iterations it thought there was no point in doing work of restoring solutions etc. I have fixes so that it will restore (unless in Cbc). This was cause of bug you saw.</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">b) However there were still problems. Even if you ask for dual, Clp can decide it prefers primal (you can override this but it could still happen that it decided it had to switch). If you finish then it doesn't matter, but if you hit maximum iterations in primal then objective could be high.</span><br style="font-family:arial,sans-serif;font-size:13px">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">My current fix is to add a new secondary status which signals this condition.</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">The secondary status is set to "10" in the scenario described in b).</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Cheers,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Ted</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 2:39 PM, Ted Ralphs <span dir="ltr"><<a href="mailto:ted@lehigh.edu" target="_blank">ted@lehigh.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div>To reproduce, check out current SYMPHONY trunk and build:<br>
<br></div>svn co <a href="https://projects.coin-or.org/svn/SYMPHONY/trunk" target="_blank">https://projects.coin-or.org/svn/SYMPHONY/trunk</a> SYMPHONY-trunk<br>
</div>mkdir build<br></div>cd build<br></div>../configure --enable-debug --enable-gnu-packages<br></div>make install<br><br></div>Create a parameter file "par" with the following contents:<br><br>use_hot_starts 0<br>
should_use_rel_br 0<br>do_primal_heuristic 0<br>limit_strong_branching_time 0<br><br></div><div>Run this command under a debugger:<br></div><div><br></div>symphony -F fast0507.mps -f par<br><br></div>Around line 1580 of lp_branch.c is where the solves happen in the strong branching loop. If you display "can->objval" on line 1601 each time through the loop, you will see the result of the strong branching pre-solves. What cannot happen is for both objective values to be above 161, since that would imply that the objective value for the MIP is above 161, whereas 161 is the true optimum (note that there is an objective offset of 13 in this example---the optimum including the offset is 174). <br>
<br></div>If you just keep looping until you see a case where can->objval has two values above 161, this is apparently a bug. Something like<br><br></div>(gdb) print can->objval<br><div>can->objval = {161.14556667654873, 161.14556667654873, 0, 0}<br>
<br>For me, it happens with the third candidate. If you then go and debug the solve call for one of these buggy LP calls (line 1584) and stop in hitMaximumIterations() when hitMax gets value "true", you will be able to see what I'm talking about. From within hitMaximumIterations(), the LP value seems correct, but as you step out of the solve call, the objective value gets changed in computeObjectiveValue() at some point and becomes incorrect.<br>
<br></div><div>If you change the value of use_hot_starts to 1 in the parameter file, everything is fine.<br></div><div><br></div><div>Let me know if you have trouble reproducing.<br><br></div><div>Cheers,<br><br>Ted<br></div>
<div><br> <br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 1:43 PM, Ted Ralphs <span dir="ltr"><<a href="mailto:ted@lehigh.edu" target="_blank">ted@lehigh.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Mon, Aug 18, 2014 at 12:58 PM, John Forrest <span dir="ltr"><<a href="mailto:john.forrest@fastercoin.com" target="_blank">john.forrest@fastercoin.com</a>></span> wrote:<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>Ted,<br>
<br>
2. - as described - is not a bug - you have to say solve or dual
or similar before -solution $. Clp is just giving you the
solution before solving it. <br></div></div></blockquote><div><br></div></div><div>Ah yes, you are right! However, in my stupidity, I might have stumbled onto a clue. The solution that Clp is giving me before solving on the command line is precisely the one I am seeing from within SYMPHONY. Inside SYMPHONY, I am definitely making the solve call first. It doesn't seem like that can be a coincidence. What is this solution it produces before solving?<br>
</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
1. probably is a bug<br>
<br>
What version of SYMPHONY should I check out to debug this - and
how do I reproduce bugs?<br></div></div></blockquote><div><br></div></div><div>It's SYMPHONY trunk. I'll check in my code and send you the details of how to reproduce in a separate e-mail. Thanks!<br><br></div>
<div>
Cheers,<br><br>Ted<br></div></div><div>-- <br>Dr. Ted Ralphs<br>Associate Professor, Lehigh University<br><a href="tel:%28610%29%20628-1280" value="+16106281280" target="_blank">(610) 628-1280</a><br>ted 'at' lehigh 'dot' edu<br>
<a href="http://coral.ie.lehigh.edu/~ted" target="_blank">coral.ie.lehigh.edu/~ted</a><br>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Dr. Ted Ralphs<br>Associate Professor, Lehigh University<br><a href="tel:%28610%29%20628-1280" value="+16106281280" target="_blank">(610) 628-1280</a><br>ted 'at' lehigh 'dot' edu<br>
<a href="http://coral.ie.lehigh.edu/~ted" target="_blank">coral.ie.lehigh.edu/~ted</a><br>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Dr. Ted Ralphs<br>Associate Professor, Lehigh University<br>(610) 628-1280<br>ted 'at' lehigh 'dot' edu<br><a href="http://coral.ie.lehigh.edu/~ted" target="_blank">coral.ie.lehigh.edu/~ted</a><br>
</div>