What are the use cases for `branch-only-values` in a forecast period?

[caindy]

@getorymckeag can you elaborate the use case for this? https://github.com/trolie/spec/blob/1.0.0-wip/docs/_data/components/schemas/forecast-rating-period.yaml#L35

I've read the description a couple of times, and I think I recall the use case being something like:

As an RC/TP hosting a Clearinghouse I want my Forecast Limits Snapshot to include both the limit determined under the implicit topology and the effective limit under a most-limiting contingency that implies an alternative topology of the facility's/facilities underlying a branch.

Do I have that right?

To make sure our discussion here starts on the same page, I'll revisit some terminology for context.

• A Segment is a Power System Object representing all of the series-connected (not necessarily contiguous) equipment in a Transmission Facility that is the responsibility of a particular Ratings Provider under the implicit topology.
• A Rating is an Operating Limit during a Period of an Operational Window that is/was Proposed by a Ratings Provider for a particular Power System Object.
• The Operating Limits for Transmission Facilities are determined by the Transmission Provider's Clearinghouse after considering all Proposals for the Power System Objects associated with that Transmission Facility during a particular Period of an Operational Window.

Do we need to introduce "branch" to articulate the use case you had in mind? Or is there a more general way to accommodate the use case?

Some hopefully helpful background. As you noted in the description of the schema linked above for forecast-rating-period, the Ratings Provider should of course include any planned topology changes when determine their segment rating; this is what I mean above by the "implicit topology". On the other hand, the actual topology (as determined by telemetry) can be used in a clearinghouse to determine which segments should be considered when determining the... here I want to say branch limit, but thus far we've been restricted to "overall transmission facility limit".

[getorymckeag]

Can I get back to you on this in a week or two? If you'll recall, our network apps guys are the ones that said this is needed. It recently came up in a call with ISO New England, whose SMEs are fairly convinced that not only is it not needed, but actively confusing and probably not right. Our SMEs and ISO's are going to do some head butting, and as a result of that conversation, I expect one of two outcomes:

• I'm able to add a lot more clarity to this, or
• It goes away.

[catkins-miso]

Yes, I intend to deprecate it in my current branch. I'll call it out when I open the PR. I'll probably keep it around by copying the schema to new file named ...-deprecated.yaml, then delete it from the current schema file that is linked in. We can follow this and delete/rename deprecated files as appropriate. I'll keep this issue open until then.

[getorymckeag]

Can we please push this out of the milestone? I've been asking for this to be resolved, and people internal to GE are still arguing about it. I expect it to take another month or so at least before it is presented to all our customer stakeholders and I can honestly get back with a decision.

[catkins-miso]

I'm still picking at this, but I think we're going to need to accommodate something like a (completely optional) "segment alternate rating type" where the type is managed the way we manage the emergency durations.

[getorymckeag]

Closed as obsolete