help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] Suggestions to solve the master problem faster in a Bran


From: Sylvain Fournier
Subject: Re: [Help-glpk] Suggestions to solve the master problem faster in a Branch-and-Price model.
Date: Mon, 24 Mar 2014 10:25:34 -0300

Thanks for your answer Andrew.
When I have to remove a basic variable, I fix its bound using the GLP_FX constant as Heinrich suggested, and when I have to remove a non-basic constraint, I unbind it using GLP_FR, before removing them from the problem object in a further iteration where the variable is no more basic or the constraint becomes basic. I used this logic to obtain the output I sent in the first e-mail. If I had directly removed from the problem object at least either one basic variable or one non-basic constraint, the output would have started at iteration 1 with an objective value of 0.
Note that the infeasibility value of 1995 at the first iteration must be the cause of the rather high processing time. In this example really a lot of variables and constraints were removed using the logic I described (although now I don't know exactly how many).
The other possibility you give is making a variable non-basic (instead of fixing its bounds) or making a constraint basic (instead of "freeing" its bounds). Would it make GLPK solve the problem faster? How can it be done? Is it just setting the status of the given variable/constraint? (but this would make the basis invalid, wouldn't it?)

Sylvain Fournier
Analista de Pesquisa Operacional
48 3239-2423
WPLEX Software Ltda.
Rod SC 401 no. 8600 Corporate Park bloco 5 sala 101
88050-000 Santo Antônio de Lisboa, Florianópolis SC +55 48 3239-2400
wplex.com.br
WPLEX



2014-03-22 4:23 GMT-03:00 Andrew Makhorin <address@hidden>:

> Now my question is: should I solve the model from scratch in the case
> I have to remove a lot of variables?

Generally, not.

> Or is there a parameter configuration I should use in my specific
> case?
>

Glp_simplex always starts the search from the current basis which is
provided in glp_prob by means of the statuses of rows and columns. This
allows to continue the search (re-optimize) efficiently if you obtain an
optimal basis, change the lp, and then call glp_simplex once again.
However, in this case you need to make sure that the row/column statuses
define a "correct" basis--the number of basic auxiliary/structural
variables should be equal to the number of rows, and the basis matrix
consisting of columns of basic variables, including unity ones for
auxiliary variables, should be non-singular. For example, removing an
active (more precisely, binding) constraint, i.e. a non-basic row, makes
the basis incorrect. To avoid this you may either remove the row
"logically" by making it free (unbounded) rather to remove it
"physically", or make the row basic (non-binding) before removing it by
changing the row/column statuses in an appropriate way.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]