switch-model / switch

A Modern Platform for Planning High-Renewable Power Systems
http://switch-model.org/
Other
129 stars 85 forks source link

Compatibility with Pyomo 5.6.1 #105

Closed mfripp closed 5 years ago

mfripp commented 5 years ago

Pyomo 5.6.1 introduces some changes that can break Switch models. One is that it adds a util object to pyomo.environ, which masks a util module imported in switch_model.hawaii.save_results, used by the main Hawaii model (users get "AttributeError: 'module' object has no attribute 'write_table'").

I also saw problems (maybe the same one) when trying to run the advanced demand response model with Pyomo 5.6.1.

A quick fix is to roll back to Pyomo 5.1.1, but that is not sustainable long-term.

bmaluenda commented 5 years ago

Is it possible to rename the switch_model.hawaii.util module to something different then? That might be a quick fix.

mfripp commented 5 years ago

Yes, I can do that, or move the pyomo.environ import to the top so it doesn’t mask anything else. Shouldn’t be too hard, but I needed a note to remind myself to do it.

In the longer run it may be best to switch to import pyomo.environ as pyo instead of from pyomo.environ import *. That would make the code a little messier but also more ‘Pythonic’ and easier to understand.

Matthias

On Mar 5, 2019, at 3:08 AM, Benjamin Maluenda notifications@github.com wrote:

Is it possible to rename the switch_model.hawaii.util module to something different then? That might be a quick fix.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

josiahjohnston commented 5 years ago

+1 on quick fix of changing this: import switch_model.hawaii.util as util to this: import switch_model.hawaii.util as hi_util

+1 that a better long-term solution is to make the import more explicit somehow, and I agree with your pros/cons of using import pyomo.environ as pyo. I reviewed the pyomo/environ/__init__.py in their latest release, and there is no clear list of what is imported because they have nested layers of from pyomo.X import * rather than defining __all__ with an explicit list.

If the pyo. prefix was too cumbersome, we could make an explicit list of imports ourselves like so:

switch_model.pyomo_imports

from pyomo.environ import Set, Constraint, Param, Var, ...
__all__ = ['Set', 'Constraint', 'Param', 'Var', ...]

Then normal modules would change from pyomo.environ import * to from switch_model.pyomo_imports import *

josiahjohnston commented 5 years ago

It appears this has been resolved in the short-term by importing our util module after pyomo. Ex:

...
from pyomo.environ import *
import switch_model.hawaii.util as util
...

As a perk, that solution is closer to the PEP 8 style guide for imports which recommends dividing imports into three sequential sections: standard library imports, 3rd party imports, and local applications imports.

As far as I know, our code base currently works with Pyomo v5.6.6 so I'm closing this issue as part of housekeeping. Please re-open if I am incorrect.