catkins-miso
commented
1 month ago @travis-qualus as an interop spec, we felt it was prudent to support defining ratings in ways that are in practical use.
As the documentation inline in the spec currently reads:
In practice, most exchanges will only support one kind of limit for proposals and snapshots. However, the specification supports defining limits on a per resource basis as well as limit types that are not anticipated to be used to implement Order 881.
MISO for example needs to allow interface limits to be forecasted in MW in addition to MVA for lines/transformers. I believe ISO NE supports 2 or 3 kinds of ratings from its TOs.
Encoding this flexibility in a clean JSON schema lends itself to some verbosity; it's true.
We also initially considered a map construct of "duration acronym":numeric rating value, but we didn't find a way to do this well, as discussed a bit here: https://github.com/trolie/spec/issues/3#issuecomment-1925374012
That combined with the flexibility needs around emergency durations described in https://github.com/trolie/spec/issues/121#issuecomment-2248660186 has led to the current design.
The current Ratings format object seems overly structured and verbose, resulting in a massive payload that could be considerably reduced. I've read the "Performance Trade-offs discussion" (https://trolie.energy/articles/tradeoffs.html) but I don't think we need to violate those considerations by looking at other implementation options.
The current structure is almost 360 bytes per rating. With 100 resources and 240 hours per forecast, that is 24,000 ratings or 8.64mb.
An alternative flattened structure could rely on the reality that almost all markets have 3 or 4 pre-defined conditions for which they require ratings - normal (NOR), long-term emergency (LTE), short-term emergency (STE), and [optionally] dump all load (DAL). In any case, these conditions and durations are predetermined and constant for a given RC. A given RC will also require ratings in a specific unit (typically MVA or MW). A TO could optionally provide both units.
{ "period-start": "2025-11-01T01:00:00-05:00", "period-end": "2025-11-01T02:00:00-05:00", "limits-mva": [ "nor": 160, "lte": 165, "ste": 170, "dal": 170 ] }
This is less than half the size, saving over 4.5mb per file. I don't know that we should rely on compression to keep these files to a reasonable size.