-
Notifications
You must be signed in to change notification settings - Fork 5
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
adding stale linking variables explicitly to pyomoNLP #43
base: main_branch
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this!
Unfortunately, the stale
attribute on variables is only updated/checked when the model goes to a solver. Initially, all variables are marked as stale.
Do we even need to check for staleness? I think we can just put all of the linking variables in the export_nonlinear_variables
list.
@@ -197,7 +197,9 @@ def _setup(self, start_t: float, end_t: float): | |||
start_t=_start_t, | |||
end_t=_end_t, | |||
add_init_conditions=add_init_conditions) | |||
self._nlps[ndx] = nlp = InteriorPointInterface(pyomo_model=pyomo_model) | |||
start_stale_names = [v.name for v in start_states if v.stale] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use a ComponentSet
here to avoid using names:
from pyomo.common.collections import ComponentSet
start_stale_vars = ComponentSet(v for v in start_states if v.stale)
stale_vars = [v for v in start_states if v.stale] + [v for v in end_states if v.stale and v not in start_stale_vars]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, makes sense. Yes I think you're right, we probably can put all linking variables in the list, since they would be written anyway if they're not stale. Do you think checking for duplicates between start_states
and end_states
is necessary? I don't know how the writer behaves if the same variable occurs multiple times in export_nonlinear_variables
.
…sing ComponentSet
Looks like some of the tests are failing. I'll take a look, but probably not until next week. |
This addresses the bug where an error is thrown when a linking variable is stale within a time block. The stale linking variables are passed explicitly to the .nl file writer in pyomoNLP, so that they can be found in the _vardata_to_idx map later. In the dynamic Schur interface class, the stale linking variables are selected from the start and end states. There might be a more 'pyomo' way to avoid duplicates when passing the variables, here I did this based on variable name.