Try applying stress-period PRM via operating reserves instead of load

[patrickbrown4]

Summary

We currently implement the PRM by scaling up the stress-period load:

ReEDS/reeds/core/solve/2_temporal_params.gms

Lines 774 to 775 in 915def1

	* Stress-period load is scaled up by PRM
	load_exog(r,h,t)$h_stress(h) = load_exog(r,h,t) * (1 + prm(r,t)) ;

That's ok if the stress periods have negligible weight (we currently give them a weight of 6 hours / 8766 hours per year, or 0.07% of the total):

ReEDS/reeds/input_processing/hourly_writetimeseries.py

Lines 623 to 625 in 915def1

	## Stress period hours are scaled to sum to 6 hours, making 8766 hours (365.25 days) per year
	if periodtype.startswith('stress'):
	hours = hours / hours.sum() * 6

But if we increase their weight, we'd increase the overcounting of the PRM as actual load.

Reasons to consider increasing the stress period weight:

• Better capture frequency of peak- and near-peak conditions, which might allow us to get rid of the min-CF constraint
• Model energy constraints for LDES (H2) during stress periods, as on pb/7year
• Potentially help incorporate peaker operations into state policy considerations

Proposed Changes

It seems like most of the functionality we need for an hourly PRM is already handled by the existing OPRES constraints (which are turned off by default). A rough outline of repurposing these for the PRM would be:

• Add prm as a new ortype
• Move the PRM from a load multiplier into the orperc parameter
• Probably separate control of the PRM functionality from the other operating reserve switches
• Double check all the transmission flow constraints, since I've made changes to these over the years without thinking about operating reserves
• Test to make sure the runtime impact isn't too bad. If it is, figure out how to simplify.
  • Can we aggregate OPRES(ortype,i,v,r,h,t) over v or i?
    • If that breaks other operating reserve functionality, can we make a similar PRM(r,h,t) variable?