[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] Conflict graph is too big
From: |
Robbie Morrison |
Subject: |
Re: [Help-glpk] Conflict graph is too big |
Date: |
Tue, 10 May 2011 07:13:17 +1200 (NZST) |
User-agent: |
SquirrelMail/1.4.17 |
------------------------------------------------------------
Subject: Re: [Help-glpk] Conflict graph is too big
From: Andrew Makhorin
Date: Mon, 09 May 2011 17:46:52 +0400
------------------------------------------------------------
[snip]
> Your problem is hard for glpk to be solved to
> optimality. In such cases you may either wait for a
> time or, if you are not interested in exact optimum,
> specify a time limit (say, --tmlin 600) or a mip gap
> (say, --mipgap 0.10).
>
> I managed to solve your mip to optimality for 2 minutes
> using --gomory (gomory cuts) and --pcost (pseudo-cost
> branching):
Hello Lizzy, everybody
It would not be difficult to write a script that
submitted different sets of parameters to "GLPSOL
--tmlim 3600" say and produced a report. The kind of
job that could be run overnight. Or the --mipgap could
be set wide and increasingly tightened. Similar
functionality could even be built into GLPSOL ..
although I don't see any real merit in that.
I rather suspect that this comment prompts the notion
of solver tuning and adaptive behavior. And that there
has been a lot of work done on classifying problems and
matching solvers (that I am totally unaware of).
best wishes, Robbie
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred) : address@hidden
[from Webmail client]