-
Notifications
You must be signed in to change notification settings - Fork 517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
component_data_objects(active=False) does not yield correct objects #443
Comments
This isn't isolated to GDP, I can recreate this using Constraints. |
I tried to raise this issue about 3 years ago on trac (https://software.sandia.gov/trac/pyomo/ticket/4595). It was largely ignored. In Kernel, the component iterators only accept active=True/None to avoid this issue. |
Looks like this is being caused by |
I'm ok with requiring |
@blnicho: correct. We have been burned by using the same flag for the block iteration and the component identification in the past. The original motivation was searching for active components, where an active constraint within an inactive block should not be returned. But that has caused initially surprising side effects. @qtothec: the restriction to
The best solution is probably to change how we handle |
@jsiirola: If that behavior is unintuitive, it is a reflection of poor documentation for that method. Either I believe I've handled this correctly in Kernel for both pre-order and post-order traversal. The documentation there could be made more clear about it though. |
I hit something similar when passing the In the following script, it appears vars do not get generated when import pyomo.environ as pyo
m = pyo.ConcreteModel()
m.b = pyo.Block()
m.v = pyo.Var()
print("active=False")
m.deactivate()
m.b.deactivate()
for comp in m.component_objects(pyo.Var, active=False):
print(comp.name)
print("active=True")
m.activate()
m.b.activate()
for comp in m.component_objects(pyo.Var, active=True):
print(comp.name) The output is: active=False
active=True
b.v where I would have expected: active=False
b.v
active=True
b.v Edited to add Edit 2: This behavior appears to be because |
Test case
Discovered by @sjkale. Simple GDP test example. Trying to find inactive disjunctions using
component_data_objects
not working. Tested on fd2bd02.Expected output
Actual output
The text was updated successfully, but these errors were encountered: