Add structure for moving report.gms to Python

[patrickbrown4]

Summary

Following in the vein of #61 and #139, this PR adds a structure for moving the calculations in report.gms to Python and uses it for a couple blocks of outputs as examples.

Technical details

Implementation notes

The proposed structure is:

• Sets, parameters, and output variables necessary for output-processing calculations are added in report_data.csv (in reeds/core/terminus)
  • These get written to a new intermediate file, {case}/outputs/results.gdx
  • Output variables always include all attributes (level, marginal, upper/lower bound, scale)
• The existing report_dump.py calls a new report_calcs.main(), which returns a dictionary of output parameters calculated in Python. These parameters then get written to {case}/outputs/{param}.csv and/or {case}/outputs/outputs.h5, as usual.
• report_calcs.main() has some helper functions for common operations at the top, followed by blocks of calculations for the different types of outputs.
  • Only the transmission, CO2 storage, and interconnection queue outputs are currently included; additional sections can be moved over in batches in subsequent PRs.

Some notes given the current mix of standards:

• Parameters that are moved from report.gms to report_calcs.py are listed in a block comment at the top of report.gms, so searching for them will turn up both scripts.
• Parameters not calculated in report.gms will not show up in {case}/outputs/rep_{case}.gdx
  • But {case}/outputs/outputs.h5 is unchanged
• It's possible that doing these calculations in Python may be slower than doing them in GAMS, particularly for big hourly outputs, but some notes on potential speedups are added as comments in report_calcs.py

Additional changes

A new reeds.results.diff_outputs() function has been added. This function works like gdxdiff but for outputs.h5 files, and can be used to do a global comparison of outputs between pairs of cases.

Validation, testing, and comparison report(s)

Zero change for the USA_defaults case: results-v20260708_mainK0_USA_defaults,v20260709_reportK0_USA_defaults.pptx

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 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

No

[patrickbrown4]

The method on main is off for years before the last year; see #146. This implementation fixes it and is self-consistent when stress periods are always weighted at 6 hours per solve year, but if #146 is fixed as suggested, we should instead use hours_h(allh,t) here to make it future-proof in case we switch to nonuniform stress period weights.