Define Seasonal Ratings Schedule in API

[catkins-miso]

define what APIs for querying and submitting seasonal ratings through TROLIE are available

[getorymckeag]

@catkins-miso I've been working on this a bit this morning. Sharing some raw thoughts here.

I see that there are these two fundamental views of seasonal ratings- one from the perspective of a schedule- so, you could think of asking for seasonal ratings that are applicable from 3/1 to 6/1. You could return a schedule, or perhaps a single set of ratings, selecting the most limiting value across that schedule. I kind of feel like this is often what will be needed for planning studies, although in that scenario you would probably want to filter out seasonal rating overrides that happen over that period. Or, at least have the option to do so.

Then, for the outage coordination use case, this goes more into an hourly(ish) forecast that includes ALL forecasted ratings, which would be AARs up to 10 days + seasonal ratings + seasonal overrides + temporary AAR exceptions.

There is this convention too, or "named buckets" as I call them below. There may be a need to query by the named buckets, or it may simply be desirable to ensure that seasonal rating submissions match up with those named buckets.

What I'm currently pondering is which of these use-cases is TROLIE-worthy. I am thinking that the named buckets use case stays out of TROLIE entirely- we assume that any restriction to particular months, month ends etc are details of the TROLIE server implementation. It probably makes more sense to consider seasonal ratings in terms of a start and end period, as this makes us agnostic to convention and gives the TROLIE server and client an opportunity to exchange over disparate technology and business rules.

Now, we've talked about the idea of a "beyond 10 days" forecast as being out there, with the most common use case being outage coordination. I'm thinking about the planning use case- there, what they typically would want (at least as to my understanding) is to simply get A SINGLE rating (or perhaps day/night pair) for each facility that applies over a broad period, such as June to September. It could be up to the TROLIE server to define what that means, as there are a number of business rules you might consider. I would think however that the typical ask would be for something that gives better accuracy for these "big picture" level studies done during planning- so, you probably want to leave any seasonal ratings overrides out, as these should be temporary conditions. Rather, the TROLIE server would simply select the most limiting "proper" seasonal rating for that period.

[catkins-miso]

for the outage coordination use case, this goes more into an hourly(ish) forecast that includes ALL forecasted ratings, which would be AARs up to 10 days + seasonal ratings + seasonal overrides + temporary AAR exceptions.

There are other consumers of this in forward operations, but yes, this is the static rating forecast we discussed early in #127.

A SINGLE rating (or perhaps day/night pair) for each facility that applies over a broad period, such as June to September.

This could be as simple as asking for the seasonal ratings schedule for one hour (or two for day and night), I believe. Typically, the use case is an on- / off-peak "winter" or "summer" rating.

I am thinking that the named buckets use case stays out of TROLIE entirely- we assume that any restriction to particular months, month ends etc are details of the TROLIE server implementation. It probably makes more sense to consider seasonal ratings in terms of a start and end period, as this makes us agnostic to convention

I agree with this. A "bucket name" is just a free-text field that can be associated with an extent in the provided seasonal ratings schedule.

The main distinction here is that a seasonal ratings schedule is not a forecast. Though it can certainly include approved projects that would represent durable changes to the facility which are inputs to the calculation of a seasonal rating.

That said, I think that's mostly just semantics in the request; the seasonal ratings schedule representation could use the same layout as the forecast snapshot.

so, you probably want to leave any seasonal ratings overrides out, as these should be temporary conditions. Rather, the TROLIE server would simply select the most limiting "proper" seasonal rating for that period.

Exactly.

[getorymckeag]

@catkins-miso I'm looking at the description on this issue and wondering if I put it in the milestone perhaps by mistake, and this one goes a good deal further out. There's sort of a baked in assumption here using your terminology of the Obligation Profile that this is more about modeled seasonal ratings, and their use in a conformance testing suite. What I need to do, much more urgently (and is the purpose of this milestone) is to define what APIs for querying and submitting seasonal ratings through TROLIE are available. Should we keep this issue? Should we move it out of the milestone?

[catkins-miso]

define what APIs for querying and submitting seasonal ratings through TROLIE are available

I'll rename this issue and create a "conformance tests" milestone that includes issues around test data conventions. When I created this issue, I was trying to pin down the information content and semantics of "seasonal ratings schedule" for the purposes of the model side load (ostensibly for conformance testing but also to support MISO's modeling efforts).

That said, I think the main difference between what this issue is now and what it started as is just syntax for the most part. Here we're talking about PUT/POSTing a seasonal ratings schedule and in the conformance test we want to be able to pull that information in as a testing baseline.