<div>Hi Martin and all.</div><div><br></div><div>I just tried this out: I add all needed rows/constraint just once and after that I just turn "on" and "off" (setting upper and lower bounds to double -max()/+max()) the ones that are and are not needed, respectively. So far, the performance dropped down steeply. Could I be doing something wrong? Or could this be the correct result?</div>
<div><br></div><div>Regards,</div>--<br>Carlos E. Knippschild<br>
<br><br><div class="gmail_quote">On Fri, Feb 5, 2010 at 16:07, Carlos Eduardo Knippschild <span dir="ltr"><<a href="mailto:carlos.eduardo@audaces.com.br">carlos.eduardo@audaces.com.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey Martin.<div><br></div><div>Thanks for the prompt answer! </div><div><br></div><div>So you mean I should add all constraints that would ever be used and then just "enable" and "disable" according to the current model I want to solve, right? Instead of "real" slacks variables, couldn't I just use the values row/constraint upper and lower bounds to do the enabling/disabling?</div>
<div><br></div><div>Best wishes!<br clear="all"><font color="#888888">--<br>Carlos E. Knippschild</font><div><div></div><div class="h5"><br>
<br><br><div class="gmail_quote">On Fri, Feb 5, 2010 at 15:59, Mueller, Martin C <span dir="ltr"><<a href="mailto:martin.c.mueller@siemens.com" target="_blank">martin.c.mueller@siemens.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Carlos,<br>
<br>
You're probably better off changing bounds instead of adding or deleting rows. In cases such as yours I usually just add a slack variable to each of these rows. Fixing the variable to zero switches the row on, removing all bounds switches it off. The solver can more easily warmstart the resolve.<br>
<br>
With best regards,<br>
Martin C Mueller<br>
<br>
Siemens AG<br>
Corporate Technology<br>
CT T DE TC3<br>
Otto-Hahn-Ring 6<br>
81739 Munich, Germany<br>
Tel.: +49 (89) 636-42373<br>
Fax: +49 (89) 636-42284<br>
Mobile: +49 (170) 9950406<br>
mailto:<a href="mailto:martin.c.mueller@siemens.com" target="_blank">martin.c.mueller@siemens.com</a><br>
<br>
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322<br>
<br>
Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.<br>
<div><div></div><div><br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:clp-bounces@list.coin-or.org" target="_blank">clp-bounces@list.coin-or.org</a><br>
> [mailto:<a href="mailto:clp-bounces@list.coin-or.org" target="_blank">clp-bounces@list.coin-or.org</a>] On Behalf Of Carlos<br>
> Eduardo Knippschild<br>
> Sent: Friday, February 05, 2010 6:44 PM<br>
> To: CLP user list<br>
> Subject: [Clp] Solving a lot of small and similar LPs<br>
><br>
> Hello.<br>
><br>
> I'd like to know if anyone has some suggestions on how to<br>
> improve solving performance for our case, for which we're<br>
> currently using CLP.<br>
><br>
> We're trying to solve tens to hundreds of thousands of<br>
> dynamically generated LPs, ranging from 30 variables by 500<br>
> constraints to a maximum of 400 variables by 100 000<br>
> constraints. Each new generated LP is a small modification<br>
> from the one previously solved, where these modifications are<br>
> always the addition or removal of constraints (the number of<br>
> variables remains always the same) by using methods "addRow"<br>
> and "deleteRows" on the existing model.<br>
><br>
> I've already played a little bit with some of the parameters<br>
> I've found, and so far I discovered that by disabling<br>
> presolve and scaling we improve a little our times.<br>
><br>
> So, does anyone have any ideas on how to get even better<br>
> results? Are there better ways of keeping this ever changing<br>
> model? What other parameters should I play with?<br>
><br>
> Or even, if another project from COIN-OR would be more<br>
> suitable for our case. Recently I read about DyLP: would it<br>
> be an interesting option for this case?<br>
><br>
><br>
> Thank you for your time! Any help will be much appreciated.<br>
><br>
> Regards,<br>
> --<br>
> Carlos E. Knippschild<br>
> </div></div></blockquote></div><br></div></div></div>
</blockquote></div><br>