[Clp] Solving a lot of small and similar LPs

[Carlos Eduardo Knippschild]

Hi Martin and all.

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?

Regards,
--
Carlos E. Knippschild


On Fri, Feb 5, 2010 at 16:07, Carlos Eduardo Knippschild <
carlos.eduardo at audaces.com.br> wrote:

> Hey Martin.
>
> Thanks for the prompt answer!
>
> 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?
>
> Best wishes!
> --
> Carlos E. Knippschild
>
>
>
> On Fri, Feb 5, 2010 at 15:59, Mueller, Martin C <
> martin.c.mueller at siemens.com> wrote:
>
>> Hi Carlos,
>>
>> 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.
>>
>> With best regards,
>> Martin C Mueller
>>
>> Siemens AG
>> Corporate Technology
>> CT T DE TC3
>> Otto-Hahn-Ring 6
>> 81739 Munich, Germany
>> Tel.: +49 (89) 636-42373
>> Fax: +49 (89) 636-42284
>> Mobile: +49 (170) 9950406
>> mailto:martin.c.mueller at siemens.com
>>
>> 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
>>
>> 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.
>>
>>
>> > -----Original Message-----
>> > From: clp-bounces at list.coin-or.org
>> > [mailto:clp-bounces at list.coin-or.org] On Behalf Of Carlos
>> > Eduardo Knippschild
>> > Sent: Friday, February 05, 2010 6:44 PM
>> > To: CLP user list
>> > Subject: [Clp] Solving a lot of small and similar LPs
>> >
>> > Hello.
>> >
>> > I'd like to know if anyone has some suggestions on how to
>> > improve solving performance for our case, for which we're
>> > currently using CLP.
>> >
>> > We're trying to solve tens to hundreds of thousands of
>> > dynamically generated LPs, ranging from 30 variables by 500
>> > constraints to a maximum of 400 variables by 100 000
>> > constraints. Each new generated LP is a small modification
>> > from the one previously solved, where these modifications are
>> > always the addition or removal of constraints (the number of
>> > variables remains always the same) by using methods "addRow"
>> > and "deleteRows" on the existing model.
>> >
>> > I've already played a little bit with some of the parameters
>> > I've found, and so far I discovered that by disabling
>> > presolve and scaling we improve a little our times.
>> >
>> > So, does anyone have any ideas on how to get even better
>> > results? Are there better ways of keeping this ever changing
>> > model? What other parameters should I play with?
>> >
>> > Or even, if another project from COIN-OR would be more
>> > suitable for our case. Recently I read about DyLP: would it
>> > be an interesting option for this case?
>> >
>> >
>> > Thank you for your time! Any help will be much appreciated.
>> >
>> > Regards,
>> > --
>> > Carlos E. Knippschild
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/clp/attachments/20100205/ae9ed688/attachment.html>