Implement daily temperature-based gas price adjustments

[SoLaraS2]

Summary

This PR calculates daily gas price multipliers based on a linear regression fitting heating and cooling degree days on daily deviations from an annual regional gas prices (inputs/fuelprices/degree_day_gas_price_regression_parameters.csv). The user can choose between these daily regional multipliers and the existing uniform wintertime markup.

Technical details

• Added gasreg hierarchy level, which represents the regions at which the degree day / price regressions were fitted. These are mostly just census divisions, with the exceptions being "California" and "Northwest", which are components of the "Pacific" cendiv, and "Southwest" and "Mountain", which are components of the "Mountain" cendiv.
• Daily gasreg-level gas price multipliers are calculated in reeds/input_processing/fuelcostprep.py by calculating historical daily degree days for the weather years of the given run and then rescaling them to match annual degree days projected across the run's solve years. To create multipliers at the r level (needed when GSw_GasCurve = 2), the gasreg-level multipliers are copied to their constituent zones. To create multipliers at the cendiv level (needed when GSw_GasCurve != 2), the gasreg-level multipliers are combined via population-weighted average.
• Added get_daily_gas_price_multipliers function to hourly_writetimeseries.py to get a GAMS compatible csv with representative hourly NG price multipliers

Additional changes

• Added a new switch GSw_GasPriceAdjMethod which controls whether the daily price multipliers are applied or the uniform wintertime markup is applied.
• In main, the wintertime multiplier of 1.054 (szn_adj_gas_winter in scalars.csv) mentioned in the model documentation is only being applied when GSw_GasCurve = 1. A separate wintertime multiplier of 1.004 (gasprice_ref_frac_adder in scalars.csv) is being applied when GSw_GasCurve = 3. No multiplier is applied when GSw_GasCurve $\in$ [0, 2]. In this PR, the gasprice_ref_frac_adder multiplier is deleted and the szn_adj_gas multiplier is applied in every GSw_GasCurve scenario (assuming GSw_GasPriceAdjMethod = 0).
• In main, the wintertime markup only increases the wintertime price but doesn't make corresponding adjustments to maintain the pre-markup year-round average price. As a result, the year-round natural gas price is being erroneously inflated. In this PR, the adjustments are made so that wintertime prices are higher than nonwinter prices while the year-round average price is unchanged.
• In main, there are four legacy zones (p32, p35, p47, and p59) that are assigned to census divisions that don't match their state's census division (according to https://www.eia.gov/consumption/commercial/maps.php#census:~:text=CBECS%20climate%20zones-,U.S.%20census%20regions,-and%20divisions%3A). This was initially done to remedy a supply curve related issue that is now fixed, so this PR reassigns those zones to their states' census divisions for consistency with those zones' assigned gasregs.

Switches added/removed/changed

• Added GSw_GasPriceAdjMethod (0 = uniform wintertime markup, 1 = daily adjustments based on regional temperatures)

Relevant sources or documentation

Scripts for creating annual gasreg-level degree day projections and associated sources are at ReEDS-Model/ReEDS_Input_Processing@main...regional_degree_days

Validation, testing, and comparison report(s)

(in progress)

Checklist for author

Details to double-check

• Charge code provided to reviewers
• 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:
• Code formatting standardized
• Reusable functions used where possible instead of copy/pasted code (I tried my best to find preexisting relevant functions, but some may have slipped through)

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 (runbatch.py, d_solve_iterate.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

• LLMs used for timestamp compatibility between different outputs to ensure consistency in the final csv outputted
• LLMs used to run through the files and find relevant predefined functions I may have originally missed
• LLMs used to debug h5 file handling

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

[patrickbrown4]

1. How about gasreg instead of ngreg, since the techs are gas-cc/gas-ct and we don't use ng much throughout the code?
2. We'll need to add the new region level to https://reeds-model.github.io/ReEDS/model_documentation.html#figure-hierarchy (and describe the new method in the docs). If the regions are finalized, let me know and I can remake the figure.

[kodiobika]

gasreg SGTM and thanks for the heads up on the docs. The regions are finalized so if you could remake the figure that'd be great, thanks! Here's the charge code if needed: OOSP >-> 10291 - 05.18.01

[patrickbrown4]

Since this file is modified, can you run all the temporal tests from cases_test.csv and make sure they still work?

• Pacific_CC
• Pacific_weks
• Pacific_full_year
• Interday_storage
• Pacific_rep7

[kodiobika]

Thanks for your work on this! It's looking great so far -- mostly just some stylistic suggestions