getorymckeag
commented
1 day ago @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.
Put together an example of how to represent a model change that updates the seasonal rating around a planned equipment change, for example. In general, we need to start hashing out the Ratings Obligation Profile and the Seasonal Ratings Schedule representations for the conformance testing repo.