Closed Midnighter closed 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.
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.
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.
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.
?
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.
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.)
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 theGapFiller
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: