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

[jvcarag]

Summary

This pull request updates the existing pumped-storage hydropower (PSH) fleet capacity/energy data in inputs/storage/cap_existing_psh.csv to use data sourced from the 2021 U.S. Hydropower Market Report 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 using county-level PSH operational/pump capacities [MW] and max energy values [MWh] stored in inputs/storage/cap_existing_psh.csv. Sourced from the International Hydropower Association, this data currently overestimates the total capacity and max energy of the existing fleet, as it includes data from non-operational units (including proposed, under-construction, and/or paused/cancelled builds).

The replacement cap_existing_psh.csv dataset was acquired by contacting the Oak Ridge National Laboratory (ORNL) HydroSource team 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:
The GAMS parameter that stores the storage duration of the existing fleet (storage_duration_m) is defined but never applied to any model constraints. This means that regardless of the GSw_HydroPSHDurData switch setting, ReEDS will currently only ever use the default PSH storage duration defined by the selected PSH supply curve. This PR addresses this issue by assigning the parameter storing 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

2021 U.S. Hydropower Market Report:
https://www.energy.gov/sites/prod/files/2021/01/f82/us-hydropower-market-report-full-2021.pdf

Validation, testing, and comparison report(s)

DATA UPDATE

Comparing Diurnal IHA vs Diurnal ORNL:

Negligible changes to the default ReEDS case are seen as a result of the switch from IHA- to ORNL-sourced data and the use of the storage_duration_m parameter in model constraint equations. Below are generation (TWh, left) and capacity (GW, right) difference plots comparing the use of ORNL data vs IHA (base) using diurnal (default) storage representation:

Main changes to results are seen in the total energy capacity [TWh] of the system caused by large differences in energy capacity of certain existing PSH units between data sources.

Effects of this large energy capacity difference are not reflected in capacity or generation results because the diurnal (default) ReEDS seasonal storage representation does not chronologically link storage levels of technologies like pumped-storage, effectively capping energy arbitrage at diurnal frequency and preventing use of the full potential of existing pumped-storage energy capacity.

Comparing Interday IHA vs Interday ORNL

Running ReEDS using the interday representation of seasonal storage technologies show slightly different changes to generation (TWh, left) and capacity (GW, right) when comparing a run using ORNL-sourced data vs IHA (base):

Differences are still relatively negligible in the context of the entire system, though the reduction in pumped-hydro capacity when using ORNL-sourced data is expected.

Comparing Diurnal 12-hr vs Interday ORNL

The final comparison shows the difference in generation (TWh, left) and capacity (GW, right) when running ReEDS with Interday storage using ORNL data vs the diurnal 12-hr case:

Effects of ORNL Data with Interday Representation

Changes from this PR mainly affect the operating characteristics of PSH, particularly in the amount of energy that PSH capacity can arbitrage over the course of a model year. Below are various hourly state-of-charge (SoC) plots. The first plot (top) shows the effect of both interday storage representation and the old IHA data on PSH capacity SoC. The second plot (middle) is the same plot as the first, but using the new ORNL data. The third plot (bottom) isolates the effects of using the ORNL data compared to the default 12-hr PSH duration.

Compare report showing effects of {default|interday} storage representation and use of existing site {IHA|ORNL}-sourced data for storage duration calculation:
report.html

Bokeh report comparing use of ORNL-sourced existing site data vs IHA in ReEDS run using default storage representation:
report.html

Bokeh report comparing use of ORNL-sourced existing site data vs IHA in ReEDS run using interday storage representation:
report.html

BUG FIX

Negligible changes to ReEDS default results now that ReEDS properly uses existing PSH storage duration data. Below are generation (TWh, left) and capacity (GW, right) difference plots comparing a US default run before/after bug fix:

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

[stuartcohen8]

The formulation looks fine to me. @patrickbrown4 or @pesap or @kodiobika any issues with the storage duration parameter expansion?

Other than that, it'd be good to add legends to the plots, add a comparison between old defaults and the run with interday+ORNL data, and add some state of charge plots to show the difference in operation between interday and default representation for PSH.

[jvcarag]

Updated PR to include plot legends, compare plots between the "diurnal (default) 12-hr" run vs "Interday ORNL-data" run, and state-of-charge (SoC) plots

[pesap]

The formulation looks fine to me. @patrickbrown4 or @pesap or @kodiobika any issues with the storage duration parameter expansion?

Other than that, it'd be good to add legends to the plots, add a comparison between old defaults and the run with interday+ORNL data, and add some state of charge plots to show the difference in operation between interday and default representation for PSH.

we just need to change something on R2X to be able to read it!

[kodiobika]

The formulation looks fine to me. @patrickbrown4 or @pesap or @kodiobika any issues with the storage duration parameter expansion?

Other than that, it'd be good to add legends to the plots, add a comparison between old defaults and the run with interday+ORNL data, and add some state of charge plots to show the difference in operation between interday and default representation for PSH.

No concerns on my end, thanks for checking!