FINITO Link

[mmowers]

Summary

This PR provides a linkage to the FINITO model, which is currently a private repository at https://github.com/NatLabRockies/FINITO). The linkage allows the full electricity sector detail of the ReEDS model to be used in combination with the industrial (and other) sector representation of the FINITO model.

The linkage is turned off by default, so this PR itself should not have impact on ReEDS results (although very small differences were observed in out years, presumably because the ReEDS model itself was touched, even if the matrix is identical).

For a high-level overview of FINITO and the linkage points see this slide deck.

See companion FINITO PR: https://github.com/NatLabRockies/FINITO/pull/438

Technical details

Turning on the linkage adds the constraints of the FINITO model to those of the ReEDS model, and adds the two objective functions together.

To turn on the linkage, clone the FINITO model and checkout the bs/reeds_link2 branch, unless this branch has already been merged into main, at which point main.

Configure these switches:

• GSw_FINITO_Link: This switch turns on the linkage
• finito_dir: This switch needs to point to the FINITO directory as a complete, absolute path
• finito_cases_file: This switch should be the suffix of the cases file in the FINITO directory, which contains the corresponding FINITO scenario configuration
• finito_case: This switch is the specific case in finito_cases_file to be run
• first_year_finito: This switch is the first year that the linkage will be implemented

The reeds2 conda environment should be used for the linked model

Linked runs result in the the same set of ReEDS outputs, but new outputs are also added from FINITO in the finito subdirectory of the run directory.

Relevant sources or documentation

FINITO documentation is at https://github.com/NatLabRockies/FINITO

Validation, testing, and comparison report(s)

A comparison was made berfore and after this change. There was expected to be no change, but apparently adding parameters to the model (e.g. the tfuel(t) parameter) that should not change the original matrix can still result in very small differences (reduced comparison report here:
reeds_report.zip
):

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