-
Notifications
You must be signed in to change notification settings - Fork 486
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
Pyomo.DoE adds checking sentences to the type of objects #3250
base: main
Are you sure you want to change the base?
Conversation
@adowling2 This PR is ready for your review. Thank you! |
The unit test is added in the following file:
We added the unit test where in the kinetics example, the design variables are defined as |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3250 +/- ##
=======================================
Coverage 88.47% 88.47%
=======================================
Files 852 852
Lines 96222 96319 +97
=======================================
+ Hits 85131 85223 +92
- Misses 11091 11096 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
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.
@jialuw96 could you explain the motivation behind this PR? It looks like the Pyomo.DoE API was meant to support design variables specified as either Pyomo mutable Param or Var components but there were a few bugs with the Param case. Is that right?
The docstrings for the DesignOfExperiments
and DesignVariables
classes should also be updated. Right now they don't mention that both Param and Var components are accepted:
design_vars – A DesignVariables which contains the Pyomo variable names and their corresponding indices and bounds for experiment degrees of freedom
pyomo/contrib/doe/doe.py
Outdated
# If fix_opt is True, fix the design variable | ||
var.fix(design_val[name]) | ||
else: | ||
# Otherwise check optimize_option | ||
if optimize_option is None: | ||
# If optimize_option is None, unfix all design variables | ||
var.unfix() | ||
|
||
if var.ctype is Var: | ||
if fix_opt: | ||
var.fix(design_val[name]) | ||
else: | ||
# Otherwise, unfix only the design variables listed in optimize_option with value True |
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.
Why did you remove the comments explaining the logic here?
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.
This is added back
formula="central", # formula for finite difference | ||
) | ||
|
||
result2.result_analysis() |
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.
Are you expecting the results to be the same as the previous case? If so I think you should have the same assert statements checking the trace and determinant.
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.
I modified this test to use both Param
components for parameters and variables, change one parameter value, use assertions to check if the generated model uses the updated model parameter value, and check the trace and determinant.
for par in self.param: | ||
cuid = pyo.ComponentUID(par) | ||
var = cuid.find_component_on(b) |
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.
There is another copy of this code starting on line 612. Does it need to be updated also?
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.
Yes, they are updated now
pyomo/contrib/doe/doe.py
Outdated
elif var.ctype is Param: | ||
var = design_val[name] |
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.
What if this is called with fix_opt=False
? Are there cases where the user expects var
to be a degree of freedom and they would be surprised by this code silently leaving it as fixed? If this is expected behavior then I think it needs to be clear in the documentation what the tradeoff is when using a design variable declared as a Pyomo Param vs a Pyomo Var.
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.
if with fix_opt=False
, var will be unfixed, so it is fine if the user wants to leave it as DOF (they can use fix_opt=False to do that). I add a statement in the doc to note that, if a design variable is defined as Param
, stochastic_program
function will not work because it cannot be optimized.
The current Pyomo.DoE API can only support design variables and to-be-estimated parameters as
This is updated. Thank you! |
@blnicho Is this ready for review again? |
Decision: @adowling2 will work on resolving conflicts and extensive testing after #3267 is merged. This current PR is NOT critical for the Pyomo.DoE workshop next week. |
Fixes # .
No issue
Summary/Motivation:
In Pyomo.DoE, check if an object is
Var
orParam
before proceeding to fix it or set bounds to it.Changes proposed in this PR:
Var
before setting upper and lower bounds to it. If it is not a type ofVar
, no need to fix it.Var
before fixing it to a given value. If it is one type ofParam
, check if it is mutable before changing it value.Legal Acknowledgement
By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution: