Skip to content

Allow RPS/CES requirements to be enforced explicitly during stress periods - #177

Open
wesleyjcole wants to merge 19 commits into
mainfrom
wjc/ces_stress
Open

Allow RPS/CES requirements to be enforced explicitly during stress periods#177
wesleyjcole wants to merge 19 commits into
mainfrom
wjc/ces_stress

Conversation

@wesleyjcole

@wesleyjcole wesleyjcole commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Summary

This pull request adds a new switch (GSw_StateRPS_Stress) that allows users to enforce the RPS/CES requirements explicitly during the stress periods. Currently, the RPS/CES requirements are enforced only during the representative periods. By turning on the switch, the requirements can be enforced during all stress periods (with equal weighting) or during the peak load stress periods. Turning the switch on represents that a state would plan to be compliant with the RPS/CES requirement for planned stress conditions, not just for representative conditions.

The switch is off by default, so there is no change to default model behavior.

Technical details

Implementation notes

The RPS equations now include a htype set, where htype is "rep" or "stress" to indicate whether representative or stress periods are being used for the equation. Representative periods are weighted using hours(h) like before, and stress periods are weighted using "1" for any stress period included and "0" for all other stress periods.

A new linking set st_szn_stresspeak(st,allszn) is included to specify which stress period is a state's peak day.

Outputs are updated so that when the new switch is turned on, the marginal costs show up in the downstream cost reporting.

Switches added/removed/changed

GSw_StateRPS_Stress is new: 0=off (default, no change), 1=weight all modeled stress hours equally, 2=weight only each state's own peak-load stress period(s).

Known incompatibilities

The new switch only works with the stress period representation, and the peak load version of the switch only works when peak load stress days are selected. This PR includes checks for both of those conditions so an error message will indicate if a user selected an invalid combination.

Validation, testing, and comparison report(s)

Enforcing the RPS/CES requirements in the stress periods results in more firm low-emission capacity and less gas capacity:

image

As expected, the states with high CES policies experience the largest changes and build more in-state resources. You can see that in the compare report deck by flipping through slides 18-20 (maps of the generation and transmission build out).

Comparison report: results-Main,CESStress1,CESStress2.pptx

I confirmed that there are no changes with main when the GSw_StateRPS_Stress is turned off: results-Main,CESBaseline.pptx

Checklist for author

Details to double-check

  • Charge code provided to reviewers
  • Included comparison reports for appropriate test cases
  • Documentation updated if necessary
  • Code formatting standardized
  • Reusable functions used where possible instead of copy/pasted code

General information to guide review

  • Zero impact on results of default case
  • No large data file(s) added/modified
  • No substantive impact on runtime for full-US reference case
  • No substantive impact on folder size for full-US reference case
  • No change to process flow (runreeds.py, reeds/core/solve/solve.py)
  • No change to code organization
  • No change to package requirements (environment.yml or Project.toml)

Did you use LLM tools (chatbot or copilot) in the preparation of this PR? If so, describe how

Yes, I did the code design, and then implemented that design using Claude. I edited most of Claude's comments (still haven't figured out how to get the LLM to write comments I like). The model documentation changes did not use a LLM.

set RPSCat_i(RPSCat,i,st) "mapping between rps category and technologies for each state",
RecMap(i,RPSCat,st,ast,t) "Mapping set for technologies to RPS categories and indicates if credits can be sent from st to ast",
set RPSCat_i(RPSCat,i,st) "mapping between rps category and technologies for each state",
RecMap(i,RPSCat,st,ast,htype,t) "Mapping set for technologies to RPS categories and indicates if credits can be sent from st to ast",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did the htype index have to be added to RecMap?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants