Hourlymatching

[wilson-ricks]

Description

This PR updates the hourly matching policy to generalize it beyond hydrogen resources. Rather than creating a single "Qualified Supply" tag and an hourly matching constraint for each zone, it now allows for an arbitrary number of constraints (HM_1, HM_2, etc.) to be created. Demand can be added to each constraint in the following ways: via a pre-fixed time series in the Hourly_matching_requirement.csv input file, as a percentage of hourly demand in specified zones via the Hourly_matching_requirement_zonal file (similar to the current ESR policy), or as consumption from storage, flexible demand, or an electrolyzer by tagging these resources to the appropriate constraint in the Resource_hourly_matching_requirement.csv input file. Supply resources, flexible demand, and storage contribute to meeting the constraint if tagged in the same input file.

The hourly matching target (e.g. 0.9) is set via the first row entry in Hourly_matching_requirement.csv. Matching targets less than 1 are met via a new "shortfall" variable, which can contribute to the constraint in any hour but is limited in total annual quantity. A slack variable can also be created by including the Hourly_matching_requirement_slack.csv input file.

Outputs include hourly matching prices, shortfall, and slack for each HM constraint.

The Hourly_matching_requirement.csv input file is updated to reflect the correct representative periods and included in time domain reduction folder if TDR is active, but hourly matching demand is not currently considered alongside actual demand, generation profiles, or fuel profiles when building representative periods.

Separately, I noticed an apparent bug that seemed to be only including energy revenues in the net revenue calculation for outputs. I believe I've corrected this so that all revenue categories will be included.

What type of PR is this? (check all applicable)

• Feature
• Bug Fix
• Documentation Update
• Code Refactor
• Performance Improvements

Related Tickets & Documents

n/a

Checklist

• Code changes are sufficiently documented; i.e. new functions contain docstrings and .md files under /docs/src have been updated if necessary.
• The latest changes on the target branch have been incorporated, so that any conflicts are taken care of before merging. This can be accomplished either by merging in the target branch (e.g. 'git merge develop') or by rebasing on top of the target branch (e.g. 'git rebase develop'). Please do not hesitate to reach out to the GenX development team if you need help with this.
• Code has been tested to ensure all functionality works as intended.
• [unsure] CHANGELOG.md has been updated (if this is a 'notable' change).
• I consent to the release of this PR's code under the GNU General Public license.

How this can be tested

Try example systems 2 and 4, which have been updated to include hourly matching constraints and inputs. Suggest trying with the full range of includable technologies, including generation, storage, and flexible demand.

Post-approval checklist for GenX core developers

After the PR is approved

• Check that the latest changes on the target branch are incorporated, either via merge or rebase
• Remember to squash and merge if incorporating into develop

[lbonaldo]

Hey @wilson-ricks, thanks so much for this addition! I did a first round of code review and left a few minor comments directly in the code. Let me know what you think! I still need to go through the changes in the TDR module.

One part I believe is missing is the update to the model_input.md page of the documentation. It would be good to describe the new input files as well as the new settings.

A final design suggestion: for the Hourly_matching_requirement.csv file, I would recommend splitting it into two separate files, one for the targets (which could be either YAML or CSV) and another for the time series data. This would improve clarity by making sure that each row in a file has a consistent meaning and structure. (In a similar way, we were thinking about updating the Fuels_data.csv file to follow this split structure for better semantics).

Also, it seems like the Resource_hourly_matching.csv file in the example case might be redundant. Is that correct?

Thanks again!