[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] Fixing Numerical Instability Problems
From: |
GLENN RHOADS |
Subject: |
Re: [Help-glpk] Fixing Numerical Instability Problems |
Date: |
Tue, 22 Mar 2011 01:59:50 -0500 |
On Fri, 18 Mar 2011 22:43:03 +0300
Andrew Makhorin <address@hidden> wrote:
> > It may take a little while to get the "glp_write_prob" output
> because I
> > don't access to the computer resources needed to re-run these
> examples
> > (they were run by a colleague on a parallel research cluster) but I
> do
> > have a printout the LP coefficient matrices that caused a problem.
> I'm
> > including a number of these instances. Note that I'm not printing
> out
> > the last row, the last column, nor the r.h.s. because they are the
> same
> > for every LP of a given size. The last column contains a -1.0 in
> every
> > entry except the lower-right corner entry which is a zero. The
> last
> > constraint row contains a 1.0 in every entry except the lower-right
> > corner which again is a zero. Every constraint row except the last
> is
> > <= 0 (in glpk form, you add an artificial variable and have the
> > constraint = 0). The last constraint is = 1.0. All of the output
> was
> > generated by the application program except for two lines that were
> > output by glpk saying that it was unable to factorize the basis
> matrix
> > and that basis recovery hadn't been implemented yet. The fifth and
> > seventh LPs listed below were the only two in which there wasn't
> two or
> > more identical constraint rows. Sorry about the mail facility word
> > wrapping the longer constraint rows; there doesn't seem to be a way
> to
> > avoid it. If this information isn't sufficient and you really need
> to
> > see the output from glp_write_prob, let me know and I'll get that
> to
> > you when I can. Thanks very much for your time.
>
> It seems to me that the error in solution is caused by some other
> reason, at least not by linearly dependent rows. Since all your
> instances are of small size, I'd recommend the following: remove any
> calls to glp_scale_prob, and every time you need to solve a newly
> generated lp instance, call glp_std_basis and then glp_simplex with
> the
> lp presolver disabled (don't forget to check the return code from
> glp_simplex). If the error will not disappear, please post me the
> instances written in cplex lp or glpk format. Thanks.
removing the call to glp_scale_prob fixed the problems! When we
initially ran into these error, we made two changes; reset tiny numbers
that are effectively zero to exactly zero and add the call to
glp_scale_prob. Removing the scaling and leaving in the resetting of
"effective zeroes" solves the problem. :-)
Thanks for your suggestions.
-- Glenn C. Rhoads