Closed simonbowly closed 1 year ago
Hello, @simonbowly. We appreciate your suggestion! We will discuss this request and add it to our backlog for future efforts.
NOTE: There is no guarantee that we will implement all suggestions. We do, however, accept external contributions. If you are interested in expediting this request, we encourage you to review our Contribution Guide. Feel free to ask us for more details on contributing to Pyomo as well.
Summary
It would be useful to add some capability to manage Gurobi environments (
gurobipy.Env
objects) in theGurobiDirect
solver.I'm happy to submit a PR for the changes described below, but could use some guidance as to the best option that fits with pyomo's style & API.
Rationale
Some Gurobi customers using pyomo to build their models have run into issues with locking up shared resources (compute servers, floating licenses, etc). When using gurobipy directly the solution is to use context managers to explicitly free those resources once they are done with. This is tricky to achieve in pyomo since Gurobi environments are not used explicitly (the global 'default' environment is used).
Additionally, some parameters cannot be set without explicitly creating Gurobi environments e.g. ISV keys (see #2401), or MemLimit added in a recent release.
Description
Several possible solutions:
gurobipy.Env
in__init__
or__enter__
inGurobiDirect
.close()
method inGurobiDirect
to free all gurobi resourcesgurobipy
and pass it as a keyword argument toSolverFactory
Some technical points to fix:
GurobiDirect.available()
checks for a license, but if it encounters an error (e.g. the license is temporarily in use) then it tracks this outcome globally and the solver is completely locked.available()
might be better off just checking ifgurobipy
can be imported and leave the license check until a model needs to be created._solver_model
should be explicitly freed if overwrittenAdditional information
I've written some test cases to try to make the above points clear.