opencobra / optlang

optlang - sympy based mathematical programming language
http://optlang.readthedocs.org/
Apache License 2.0
244 stars 51 forks source link

GLPK integer tolerance #223

Closed Midnighter closed 3 years ago

Midnighter commented 3 years ago

Seems that the story from #220 is not completely over yet. Updating to 1.4.7 fixed most problems, except our gap filling test. In that function we specifically set the integer tolerance. As this was not supported before either for GLPLK, I don't know why it is now failing when it hasn't before...

@cdiener test_gapfilling likely needs a lower integer threshold to pass or at least, the threshold attribute of the GapFiller should not be allowed to be set to a value lower than the default value in GLPLK (1e-5).

@KristianJensen would it be bad to support integrality and optimality tolerances in GLPK? From the manual it seems that this is possible:

double tol_int (default: 1e-5) Absolute tolerance used to check if optimal solution to the current LP relaxation is integer feasible. (Do not change this parameter without detailed understanding its purpose.)

double tol_obj (default: 1e-7) Relative tolerance used to check if the objective value in optimal solution to the current LP relaxation is not better than in the best known integer feasible solution. (Do not change this parameter without detailed understanding its purpose.)

Midnighter commented 3 years ago

See also https://github.com/opencobra/cobrapy/pull/1011

KristianJensen commented 3 years ago

If GLPK supports these tolerances it should be completely fine to include them. The descriptions above are a bit cryptic to me though, and I'm not sure they actually correspond to the integrality and optimality tolerances e.g. as in cplex.

matthiaskoenig commented 3 years ago

It would be great if the tolerances could be set. Working on reproducibility of simulations between solvers and having control over the tolerances from cobrapy/optlang would make things much easier.

cdiener commented 3 years ago

This was partially discussed in https://github.com/opencobra/cobrapy/issues/941 as well. Cross-posting the relevant tolerances here:

double tol int (default: 1e-5)
Absolute tolerance used to check if optimal solution to the current LP relaxation is integer
feasible. (Do not change this parameter without detailed understanding its purpose.)

double tol obj (default: 1e-7)
Relative tolerance used to check if the objective value in optimal solution to the current LP
relaxation is not better than in the best known integer feasible solution. (Do not change this
parameter without detailed understanding its purpose.)

double mip gap (default: 0.0)
The relative mip gap tolerance. If the relative mip gap for currently known best integer feasible
solution falls below this tolerance, the solver terminates the search. This allows obtainig suboptimal
integer feasible solutions if solving the problem to optimality takes too long time.

We probably also want presolving to default to true for MIP problems (not for continuous ones though as this may hinder convergence). All of this would be easier if Configuration where generic and not solver-specific as it is now. Another common parameters I would like to set are maximum iterations. I agree with @KristianJensen evaluation that those do not exactly match what cplex uses. However, most of tose use wildly different convergence criteria anyways (mostly different norms), so pretty much any tolerance means something different for each solver.

Midnighter commented 3 years ago

I don't fully follow you Christian. The Configuration class presents a single interface to solver configuration but then instances necessarily are specific to the chosen solver. So how would you do

All of this would be easier if Configuration where generic and not solver-specific as it is now.

?

cdiener commented 3 years ago

Sorry I meant it has the same attributes and accessors for each solver. Just that some get ignored by a solver if unsupported (not sure on that one). So you would be able to set integrality tolerance on any solver but a non-mip solver would ignore it.

Midnighter commented 3 years ago

At the moment this is almost the case. Just that an AttributeError is raised instead of assignment being ignored (at least for tolerance). I think, this is okay actually because it's nice to know when a tolerance is not supported yet. (And cobrapy handles the exception.)