Description
There are two fundamental limitations of Pyomo's design that are related, which I expect to impact projects that build on top of Pyomo:
- I don't think a user/developer can reliably identify all variables used in a model
- I don't think a user/developer can reliably identify all expressions used in a model
Note that solving (2) would allow us to solve (1).
While Pyomo supports mechanisms for walking the block hierarchy, in practice a modeling component is not required to support an API with which the walker can extract the variables and/or expressions. In practice, Pyomo developers have developed walkers that know about all the different components in Pyomo. For example, the logic for the LP/GAMS/NL writers "knows" about the different components in Pyomo and, hopefully, complains when unknown components are encountered.
However, this limitation causes a problem for external libraries like PAO, which need to extract the variables and expressions in a model. Sure, we could assume that a library like PAO only operates on a model that has been transformed into a simple form (e.g. by applying all GDP transformations first). But that imposes an explicit ordering on the application of semantics that are contrary to how we claim Pyomo works. In particular, we would like to create PAO models that include the declaration of disjunctions in sub-models. But even declaring such models requires the specification of the fixed (or unfixed) variables, which assumes that we can reference a global set of fixed (or unfixed) variables.
NOTE: COEK addresses this issue by requiring a user to explicitly declare/register the variables that might be used in model expressions. I'm not sure we can rely on a similar mechanism in PAO, since a model transformation can create a variable object and put it on a part of the model that isn't discoverable via a Pyomo walker.