Initial support for supplemental attributes #1039
Conversation
|
we can create a PSY4 branch and merge the changes to that so that we can test adequately |
| ```julia | ||
| iter = get_supplemental_attributes(ForcedOutage, sys) | ||
| iter = get_supplemental_attributes(Outage, sys) | ||
| iter = get_supplemental_attributes(x -> x.forced_outage_rate >= 0.5, ForcedOutage, sys) |
There was a problem hiding this comment.
Do you have a better value to put in this example?
| @@ -241,6 +248,7 @@ export ForecastCache | |||
| export StaticTimeSeriesCache | |||
| export NormalizationFactor | |||
| export NormalizationTypes | |||
| export TimeSeriesCounts | |||
There was a problem hiding this comment.
We export get_time_series_counts which returns an instance of this struct. I don’t think a public function should return a private struct. We could argue whether that function should be exported.
| @@ -0,0 +1,63 @@ | |||
| abstract type Outage <: SupplementalAttribute end | |||
There was a problem hiding this comment.
@scdhulipala please confirm with @GordStephen that this structure is adequate for the purposes of integrating PSY into PRAS.
There was a problem hiding this comment.
As far as information needed, l think this looks good. Since there's multiple ways to store the same data, will there be a convention for which takes priority, or is that decision left to the consumer? E.g. FOR and MTTR won't necessarily be internally consistent with outage and recovery transition probabilities, or may be provided as time series vs static values. Also, seems like TimeSeriesContainer is pretty flexible as far as contents, will there be guidance around canonical names for the different possible time series stored within (presumably they'll be expected to match the struct property names)?
There was a problem hiding this comment.
As usual in PSY the data is left to the user. We can decide to limit the fields to one or the other if the additional flexibility doesn't help. I'll proceed to merge this branch into the PSY4 release branch to make further changes in a forthcoming PR.
|
partially addresses |
This functionality is not complete. Before we can make a release, we have to handle data format changes due to serialization/de-serialization adjustments. We could do that here or in a subsequent PR.