-
Notifications
You must be signed in to change notification settings - Fork 47
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
Outage timestep corrections #313
Conversation
missing -1 in indexing was causing BAU problem to be infeasible when existing techs could sustain part of outage
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.
Please update the test re: my inline comment.
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.
Please add a description to the doc string of test_critical_load_bau_can_sustain_part_outage
of what is being tested so that we do not have to read the test line by line to understand what it is doing. Can you please describe the blocks of calculations with comments? Is it only testing BAU values? (If so when we put it in REopt.jl we could run just a BAU scenario). It looks like pwf_om
is calculated but not used.
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.
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
bug fix
What is the current behavior?
When normal and critical load profiles are spliced together for the BAU problem (and zeroed out after the time steps that BAU techs can sustain), missing minus ones in indexing is causing BAU problem to be infeasible when existing techs can sustain part but not all of outage.
What is the new behavior (if this is a feature change)?
The spliced load passed to the BAU problem contains the critical load in the outage time steps up to t (where t is the last consecutive time step that the existing techs can meet load) and zeros in the outage time steps after that.
Does this PR introduce a breaking change?
no
Other information: