[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-glpk] [Fwd: Using glp_exact() after glp_simplex() has timed out]
From: |
Andrew Makhorin |
Subject: |
[Help-glpk] [Fwd: Using glp_exact() after glp_simplex() has timed out] |
Date: |
Mon, 05 Jun 2017 17:24:56 +0300 |
-------- Forwarded Message --------
From: Brendan McKay <address@hidden>
To: address@hidden
Subject: Using glp_exact() after glp_simplex() has timed out
Date: Mon, 5 Jun 2017 16:50:18 +1000
Hi, I use the exact solver for my work in combinatorics and find it
very efficient for my problems (tens to hundreds of thousands of
variables but only a few dozen constraints).
GLPK 4.61 running on Ubuntu 14.04.5 LTS.
As recommended in the manual, I call glp_simplex() first and then call
glp_exact(), which usually gives a nice speedup. It set an iteration
limit for glp_simplex() because sometimes it cycles. However, if the
call to glp_simplex() returns due the number of iterations being exceeded
(return GLP_EITLIM), sometimes glp_exact() then runs forever. I get a
never-ending sequence of outputs like this:
26194: infsum = 144 (33)
26406: infsum = 144 (33)
26619: infsum = 144 (33)
26831: infsum = 144 (33)
27044: infsum = 144 (33)
27257: infsum = 144 (33)
27469: infsum = 144 (33)
I infer that glp_simplex() is leaving things in a state unsuitable for
starting glp_exact(). In such a case it would be enough to force
glp_exact() to begin with a blank slate rather than using the
left-overs from a timed-out glp_simplex(). But how can I achieve
that short of reconstructing the problem or keeping a copy?
Thanks, Brendan.
- [Help-glpk] [Fwd: Using glp_exact() after glp_simplex() has timed out],
Andrew Makhorin <=