It was just an option I was playing around with in an attempt to try to prune earlier. I did not have time to research it much - but at first try, it didn't seem to help at all. And, clearly in cases where the compact formulation is very big - this is a bad idea.<br>
<br> //solve compact formulation first before starting PhaseI<br> // hopefully identify infeasibiity in tree quicker<br> int InitCompactSolve;<br><br><br> //---<br> //--- construct auxillary compact lp interface<br>
//---<br> if(m_param.InitCompactSolve){<br> //TODO: would be nice if we could utilize IP presolve here?<br> m_auxSI = new OsiLpSolverInterface();<br> assert(m_auxSI);<br> loadSIFromModel(m_auxSI);<br>
}<br><br><br>It should be off by default. If it is not, please let me know.<br><br>Matt<br><br><br><br><br><div class="gmail_quote">On Sat, Feb 25, 2012 at 5:13 PM, Siddhartha Jain <span dir="ltr"><<a href="mailto:sj1@cs.cmu.edu">sj1@cs.cmu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br><br>In the phaseInit method of DecompAlgoPC, the LP m_auxSI is being solved. After doing some digging, it seems like m_auxSI represents the original undecomposed problem. Is this true? <br>
<br>If so, then why is the original undecomposed problem being solved in an algorithm meant to take advantage of decomposition?<br>
<br>Thanks,<br>--Sid<br>
<br>_______________________________________________<br>
Dip mailing list<br>
<a href="mailto:Dip@list.coin-or.org">Dip@list.coin-or.org</a><br>
<a href="http://list.coin-or.org/mailman/listinfo/dip" target="_blank">http://list.coin-or.org/mailman/listinfo/dip</a><br></blockquote></div><br>