[PSH] Update PSH Supply Curves for Site-Level Processing

[jvcarag]

Summary

This PR covers the annual update of pumped-storage hydropower (PSH) supply curve input files.

PSH input files are now stored at site-level spatial resolution, and input processing procedures are modified to aggregate the site-level data up to the spatial resolution of each corresponding ReEDS run. In effect, PSH supply curves are processed using the same procedures as those used for other RSC technologies such as upv, wind-ons, and wind-ofs.

Following the standardization of supply curve input file formats, the new PSH supply curve input files consolidate the wExist and wEph siting restrictions into the "Open" case and adds a new "Limited" case with increased PSH siting restrictions from the "Reference" case. Below is a comparison of the new binned supply curves for 8-hr storage duration PSH vs the old binned supply curves:

Technical details

Site-Level PSH Supply Curve Input Files:
PSH supply curve capacity and capital cost input files are now stored in a single, site-level spatial resolution input file (previously separated and at z132-resolution), using the latitude/longitude coordinates of the lower reservoir as the site of capacity potential. The coordinates of each site's corresponding upper reservoir are also provided in the input files, available only for the purpose of post-ReEDS mapping. Interconnection and transmission costs are appended to the PSH supply curve using each site's lower reservoir latitude/longitude coordinates to map to the nearest (Euclidean distance) reV site in inputs/supply_curve/interconnection_land.h5 - by using latitude/longitude coordinates instead of sc_point_gid mapping, the PSH supply curve site locations stay independent of future updates to the reV sites in the model.

PSH Supply Curve Scenarios:
To simplify the combinations and reduce file count in inputs/supply_curve, land exclusions layers for sites utilizing existing reservoirs and/or ephemeral streams have been consolidated into 3 distinct scenarios: limited, reference, and open. Below are the exclusion layers included in each of the 3 scenarios:

• open: urbanized/developed areas, existing waterbodies, 100yr flood plains, various federal, state, and local protected areas and conservations, glaciers, snow/ice, and wetland ecosystems, and airports/airpads/helipads
• reference: all "open" exclusions [plus] ephemeral streams, critical habitats for endangered species, railways/pipelines/roads (incl. 30m buffer), and national wetlands
• limited: all "reference" exclusions [plus] agricultural lands, mature forests on federal lands, building footprints, and tribal areas (reservation and off reservation trust land)

Below are the new unbinned open, reference, and limited PSH supply curves for 8-, 10-, and 12-hr PSH storage durations:

Implementation notes

Input Files:

• Add site-level PSH supply curve files
• Update inputs/storage/PSH_supply_curves_durations.csv with entries for new PSH supply curve files
• cases.csv: update options for pshsupplycurve switch, and add numbins_psh switch for controlling PSH supply curve bin number
• Update inputs/supply_curve/dollaryear.csv with entry for new PSH supply curve files
  Input Processing
• runfiles.csv: remove old psh_supply_curves_{capacity|cost}.csv entries and add new supplycurve_psh.csv entry
• writesupplycurves.py: update procedures in agg_supplycurve() function for assembling/aggregating supply curves for use with site-level PSH supply curves.
  • New procedure clips pre-binned supply curve values at $4000/kW [2004$] to improve binning resolution at the low-cost end
• io.py: add nearest-point mapping of interconnection costs to PSH supply curve to assemble_supplycurve() function

Additional changes

• b_inputs.gms: Remove unit adjustment for pumped-hydro supply curve costs, as new input files are already stored at $/MW
• recf.csv: Remove deprecated copy argument from pd.concat() calls

Switches added/removed/changed

Issues resolved

Issue #174

Known incompatibilities

Note that while available generating capacity for PSH in ReEDS does account for frictional head losses in the conveyance system, the round-trip efficiency for PSH still uses a generic value that does not account for these losses, which are site-specific. Future work will explore ways to better account for efficiency reductions from frictional losses, either by incorporating site-level efficiencies into supply curve data or calculating a reasonable standard efficiency adjustment.

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 new parameters are added to d_objective.gms, they are included in objective_function_params.yaml for completeness checking
  • 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