Add generic demand response resources

[louisaserpe]

Summary

This PR adds back two load management methods: price-response (DR Shape) and direct load control (DR Shift). The implementation largely follows the approach Luke Lavin developed for EV managed charging, but generalizes the resources to accommodate the inclusion of other end-uses.

Technical details

Implementation notes

DR Shape

Within ReEDS, DR-Shape is an endogenous flexibility resource which:

• Is rooted in pre-computed shape resources that represent the potential for deferred demand (i.e., delayed heating, cooling, vehicle charging, etc.)
• Offered as hourly time series of fractions which represent the amount of “generation” (load that can be delayed) and additional load in a later hour (deferred from another time); these fractions are coupled with defined adoption capacities
• Amount of adopted capacity of each of these resources is a decision variable in ReEDS

DR Shift

Load shifting in ReEDS it is represented as a grid-dispatchable storage-like resource with time-dependent charge/discharge bounds. It is characterized by:

• Discharge profile: Baseline profile of DR resource available to be deferred (can also be thought of as immediate charging/use if not participating in DR)
• Charge profile: Outer bound on when DR resource can be shifted (can also be thought of as latest possible charging/payback)
• Energy profile: deferment/flexibility potential

Inputs

• Supply curve capacity: 2030 max potential of the resource [MW]
• Supply curve cost: assumed to be 0 in demonstration data [$/MW]
• Hourly profiles:
  • DR Shape: Increase/decrease fractions
  • DR Shift: charge, discharge, energy profiles
• Supply curve capacity scalars: the supply curve is populated with 2030 capacity data, the 2030 values are scaled in the model to reflect additional years through 2050
• Supply curve cost scalars: the supply curve is populated with 2030 cost data, the 2030 values are scaled in the model to reflect additional years through 2050
• VOM/FOM: assumed to be 0 in the demonstration data

Additional changes

Switches added/removed/changed

• GSw_DRShape : switch to turn on DR Shape resources
• dr_shapescen : switch to indicate which input data will be used to characterize the shape resources
• GSw_DRShift : switch to turn on DR Shift resources
• dr_shiftscen : switch to indicate which input data will be used to characterize the shift resources

The Zenodo record provides demonstration data for the DR Shape and Shift resources.

Issues resolved

Known incompatibilities

Relevant sources or documentation

The stylized data used to characterize the DR Shape and DR Shift resources are available on Zenodo

A description of the methods used to derive the stylized DR Shape data can be found in this publication (add link to preprint when available)

Validation, testing, and comparison report(s)

When DR is tuned off, there are no differences in the results for the USA defaults case: comparison report

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