[PSH] Update and Use Unit-Level Data for Existing Pumped Storage Hydropower

[jvcarag]

• Add PSH data from ORNL (to replace data in repo)
• Change relevant instances of storage_duration(i) with storage_duration_m(i,v,r)

Summary

This pull request changes the storage duration of existing pumped storage hydropower (PSH) from using the generic duration defined by the PSH supply curve to using unit-level data from the inputs/storage/storage_duration_pshdata.csv

This pull request updates the existing pumped-storage hydropower (PSH) fleet capacity/energy data to use data sourced from ORNL and fixes a bug that prevented use of PSH storage durations derived from said data.

Technical details

DATA UPDATE:
Various parameters of the existing (initial) PSH fleet, such as storage duration and charge:discharge ratio, are calculated endogenously in ReEDS input processing using operational/pump capacities and max energy values of PSH at the county level, stored in inputs/storage/cap_existing_psh.csv. This data, sourced from the International Hydropower Association, overestimates the total initial fleet capacity and generation, as it includes data from non-operational units (including proposed, under-construction, and/or paused/cancelled builds).

Replacement data was sourced from Oak Ridge National Laboratory and crossed-referenced against the IHA dataset - the ORNL dataset contains only units confirmed operational, with changes to the data resulting in an overall 8% reduction in total existing PSH operational capacity [MW] and 84% reduction in total energy capacity [MW]. The large reduction in total energy capacity is attributed to large differences in a small subset of PSH units between the IHA- and ORNL-sourced data.

BUG FIX:
In ReEDS, the storage duration used by the existing fleet is selected using the GSw_HydroPSHDurData boolean switch, where 0 derives a generic storage duration based on the selected supply curve file (pshsupplycurve switch selection) and 1 from storage durations calculated from data in inputs/storage/cap_existing_psh.csv. By default GSw_HydroPSHDurData == 1, however the storage duration data derived from cap_existing_psh.csv is never applied in the optimization model. This PR addresses this issue by assigning the parameter which stores this existing PSH storage duration data to the appropriate model constraints.

Implementation notes

• Replace IHA-sourced power and energy capacity data in inputs/storage/cap_existing_psh.csv with data sourced from ORNL
• Replace the storage_duration(i) parameter with storage_duration_m(i,r,t) for all instances in the model constraints.
  • NOTE: This implementation still allows for generic storage durations to be used if GSw_HydroPSHDurData == 0

Issues resolved

ReEDS now properly uses initial fleet storage durations based on operational and energy capacities of said initial fleet.

Relevant sources or documentation

Validation, testing, and comparison report(s)

Checklist for author

Details to double-check

• Charge code provided to reviewers
• Included comparison reports for appropriate test cases
• Documentation updated if necessary
• If input data added/modified:
  • Dollar year recorded and converted to 2004$ for GAMS
  • Timeseries are in Central Time
  • Units are specified
  • Preprocessing steps have been documented and committed to ReEDS_Input_Processing
  • New large data files handled with .h5 instead of .csv
  • If spatially resolved inputs are modified, the following visualizations for each file are included in the PR description (time-averaged if the inputs are time-resolved):
    • Map of absolute values before
    • Map of absolute values after
    • Map of differences: (after - before) or (after / before)
  • If entries are added/removed/changed in the EIA-NEMS unit database:
    • Changes have been committed to ReEDS_Input_Processing
    • hourlize/resource.py was rerun to regenerate the existing/prescribed VRE capacity data
• 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

Tag points of contact here if you would like additional review of the relevant parts of the model