You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The multiple bigM logic creates a solver interface to "gurobi" by default, which seems like a poor coding decision.
Steps to reproduce the issue
The following lines appear in a config declaration in multiple_bigm.py
CONFIG.declare(
'solver',
ConfigValue(
default=SolverFactory('gurobi'),
description="A solver to use to solve the continuous subproblems for "
"calculating the M values",
),
)
Why does it make sense to hard-code the use of gurobi within pyomo? Do we have a guarantee that this will always work and not use system resources?
Error Message
None. I found this while debugging a different issue.
Additional information
Maybe this is the intended behavior, but it seems safer to store the solver string name than the solver itself.
The text was updated successfully, but these errors were encountered:
It is less than ideal (as a solver instance is created upon import), but there is actually very little overhead in creating the interface. Ideally, I have wanted to do an overhaul of ConfigDict's implementation of default to defer the processing of the `default value until the first time the value is requested. That would allow something like:
CONFIG.declare(
'solver',
ConfigValue(
domain=SolverFactory,
default='gurobi',
description="A solver to use to solve the continuous subproblems for ""calculating the M values",
),
)
...and the actual solver object would not be created until the first time the value was accessed.
The advantage of holding the solver instance as part of the transformation configuration is that a user can both set and configure the solver before calling the transformation and those options will persist through all the solves in the transformation.
Summary
The multiple bigM logic creates a solver interface to "gurobi" by default, which seems like a poor coding decision.
Steps to reproduce the issue
The following lines appear in a config declaration in multiple_bigm.py
Why does it make sense to hard-code the use of gurobi within pyomo? Do we have a guarantee that this will always work and not use system resources?
Error Message
None. I found this while debugging a different issue.
Additional information
Maybe this is the intended behavior, but it seems safer to store the solver string name than the solver itself.
The text was updated successfully, but these errors were encountered: