Poor use of a SolverFactory?

[whart222]

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

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.

[jsiirola]

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.

[emma58]

I think John's suggestion is what we need in the long run here. Just opened it as a separate issue in #3244