Quickstart reserves

[josiahjohnston]

A module & test case for quickstart reserves, based on the pattern of spinning reserves, but without contingencies. I only implemented a single rule for quickstart reserves here (the "3+5 rule") which satisfies my immediate use case. I don't know what rules were used in the GE Hawaii RPS study, but I structured the quickstart reserve module to allow for easy subsequent extension of rules for quickstart reserve requirements (same structure as spinning reserves & spinning reserves advanced).

[bmaluenda]

Great contribution! I have two questions:

• The 3+5 criterion considers total DispatchGen summed over all renewable generators to obtain the requirement. It could be a bit more precise to calculate the requirement using DispatchUpperLimit, which considers VRE availability. Otherwise, reserve requirements in tps when there is curtailment will be artificially reduced. From my understanding, reserves are procured day-ahead, so any actual curtailment would not really affect the reserve requirement. What do you think?

• It could be useful to add a an optional parameter to specify how much capacity of a generation unit can be used to provide quickstart reserves (defaults to GenCapacity?). This could give us modeling flexibility to adapt to different definitions of quickstart reserves (some markets are more stringent than others), as well as to include different technologies. E.g. one might model a CCGT with the capability of providing quickstart reserves using only the Gas Turbines, or model a BESS system with the capability of providing quickstart reserves up to a certain fraction of its capacity (because the otehr fraction is reserved for energy arbitrage, for instance). Does this make sense?

[josiahjohnston]

Thanks for the feedback!

Hmm.. if renewables are backed away from full output to provide firmer capacity (or curtail excess energy), then I wouldn't expect they would add 5% of their output to spinning & quickstart reserve requirements based on short-term weather variability. When the 3+5 heuristic was developed in the Western Wind & Solar Integration study, I don't think people were talking about renewables providing their own reserves since renewable power costs were high and grids were still dominated by fossil and hydro generators. But at this point, it's not unheard of for renewable to operate a little below their power output to provide firmer power, or for solar developers to oversize their modules relative to their inverters based on relative component costs (which causes lower variability when the panels are providing more power than the inverters can handle).

For these reasons, I think setting it to DispatchUpperLimit instead of DispatchGen would be overestimating operating reserve requirements in cases where the values diverge, especially if DispatchGen is 95% or less of DispatchUpperLimit. I also think it would be best to keep the 3+5 requirements synchronized between spinning & operating reserves, so if we ever decided to change it in Quickstart Reserves, we'd need to update Spinning Reserves to match.

What do you think? Do those arguments sound reasonable?

Re: max_cap_for_quickstart_reserves I like the idea, but am inclined to put it on a to-do list until there is a tangible use case for it. It's similar to another to-do item of max_cap_for_spinning_reserves that would also be based on generator ramping speed and how spinning reserves are defined. This strategy of just-in-time development helps prioritize work efforts, improves the chances of design meeting actual use cases (like should parameters be units of MW, fraction of installed capacity/dispatch, or something else? details may depend on use case), and reduces the chances of having bugs in code that hasn't been fully exercised.

[bmaluenda]

Fair enough, both answers sound reasonable!

[mfripp]

There is potentially a case for counting the reserve requirement based on available renewables rather than actual dispatch. For spinning reserves, we set the largest contingency based on committed capacity, not power output. If only part of the power from the largest plant is being used, then the unused, committed capacity can be counted toward the reserve requirement, effectively reducing the reserve requirement. But the largest plant can't provide reserves for itself, because the part that is producing power always has to be covered by another plant. Something similar may apply for renewables -- curtailed renewables may be able to provide spinning reserves for non-curtailed renewables, but in total you need reserves (somewhere) equal to 5% of the available renewables, which automatically includes the renewables that are providing reserves. I would think this would be more relevant for spinning reserves, but it could apply here too.

As a more general issue -- I think the quickstart reserves should probably be a generalization of the spinning_reserves_advanced module (it could become operating_reserves). We would have different types of reserves that can be backed by either spinning capacity or non-spinning capacity, and there are rules for how much of each type of reserves can be provided by each plant. For each plant we also require that the sum of all spinning reserves provided is less than dispatch slack up (spare spinning capacity) and the sum of all spinning and quick-start (I'd call them "non-spinning") reserves is less than or equal to dispatch slack up plus commit slack up (spare spinning and non-spinning capacity). I'll see about working that up.

Back in 2015 I got bogged down even getting started on Switch 2.0 because I was focused on coming up with some data structure that could represent all the different types of reserves. I ended up creating a mini-language to describe reserve requirements and capabilities. I decided that once you're writing your own programming language you're probably in too deep, so I abandoned that and went for something simpler. I hope we're finding our way toward something simpler that can be general enough for most cases.