[ClimateHydro] Apply Climate Adjustment Factors to Hydropower CF in Input Processing

[jvcarag]

Summary

This PR moves the procedure for applying climate adjustment factors to hydropower capacity factors (CF) up to the hydcf.py input processing script instead of doing so in 2_temporal_params.gms.

Technical details

Climate adjustment factors are not being read in or applied to stress-period-indexed hydropower CF data, causing certain non-dispatchable hydro techs to have CFs of 0 for these timeslices (details are outlined in Issue #116).

Additionally, hydropower CF data used by PRAS do not include these climate adjustments, because the adjustments are not applied to the hydropower CF file ingested by the resource adequacy tool (details outlined in Issue #131).

To resolve both issues, this PR applies the climate adjustment factors to hydropower CFs when the latter are first being processed in reeds/input_processing/hydcf.py - this works because the adjustment factors and hydropower CFs are both at monthly resolution in hydcf.py, and the resulting hydcf.csv input file (used by PRAS) is the precursor to the cf_hyd.csv data that the adjustment factors are originally applied to.

Implementation notes

• In runreeds.py, climateprep.py is moved up in the input processing script order to occur right before hydcf.py: this is necessary to have the adjustment factors processed before they are applied in hydcf.py
• hydcf.py has new procedures for applying annual/seasonal climate adjustment factors to the corresponding dispatchable/non-dispatchable hydropower techs
• climateprep.py no longer creates the temp_hydadjsea.csv file, as it is no longer necessary to process seasonal adjustment factors in hourly_writetimeseries.py – as a result, the latter script no longer has procedures for processing the data from monthly to rep/stress-period resolution
• b_inputs.gms and 2_temporal_params.gms no longer read in or apply climate adjustment factors for hydropower CF, as they have already been applied to the CF data in hydcf.py

Additional changes

• runfiles.csv: added entries for the annual/seasonal hydropower CF climate adjustment factors, hydadjann.csv and hydadjsea.csv.

Switches added/removed/changed

Issues resolved

#116: Resolves issue where climate adjustments were not being applied to stress-period data, causing hydropower CFs to equal 0 for some hydro techs during stress-periods.

#131: Resolves issue where climate adjustments were not reflected in the hydropower CF data used by PRAS.

Known incompatibilities

• Climate adjustments to hydropower CF functionality (controlled by GSw_ClimateHydro) does not work out-of-the-box, as the required hydadjann.csv/hydadjsea.csv files are not currently stored in the ReEDS repo: users will need to provide their own data until updated adjustment factors are available.
• Additional work is required to apply climate adjustment factors to cooling water availability and seasonal distribution factors (details are outlined in an upcoming Issue).

Relevant sources or documentation

Validation, testing, and comparison report(s)

Below are plots comparing capacity (GW, left) and generation (TWh, right) differences before and after these PR changes:

Differences reflect the fact that climate adjustment factors are no longer dynamically weighted when converting from monthly to rep/stress-period resolution for each solve year/iteration in hourly_writetimeseries.py, as they are now "baked into" the data upstream in hydcf.py. These changes to model results are fairly negligible, resulting in a <1% change to both overall capacity and generation results.

Fixing Issue #116 also greatly increases the amount of hydropower available during stress-period dispatch, reducing the need for firm capacity technologies such as Gas-CT. Below are stress-period dispatch plots before (top) and after (bottom) PR changes:

Full bokeh compare report of USA_defaults case before/after PR changes:
report.html

Checklist for author

Details to double-check

• Charge code provided to reviewers
• Included comparison reports for appropriate test cases
• 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 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