epag
commented
2 months ago Original Redmine Comment Author Name: James (James) Original Date: 2023-01-23T13:15:49Z
There is nothing wrong with the current approach and I am not proposing to change the default, which involves declaring an order. However, an "order" is necessarily a relative thing with respect to duration and some users/use cases may prefer to declare a degree of persistence by absolute duration (with respect to the target time) rather than relative duration/position/order.
This would require an additional declaration option for a persistence source. There are a number of ways this could be done. One would be to re-use the existing @persistence@ and have an interpretation of an order or duration that depends on whether @durationUnit@ is defined. This is a bit ugly. Another option would be to define a new @persistenceDuration@, which has a default @durationUnit@ of hours. This would be fine, but would add another top-level element. The other option would be to add a flag attribute to the @persistence@ and an optional @durationUnit@, like this:
<persistence duration="false">1</persistence>
</code>The default would be @false@ (edit: for backwards compatibiilty), so equivalently:
<persistence>1</persistence>
</code>Or:
<persistence duration="true" durationUnit="hours">1</persistence>
</code>The default @durationUnit@ would be hours, so equivalently:
<persistence duration="true">1</persistence>
</code>
Author Name: James (James) Original Redmine Issue: 111822, https://vlab.noaa.gov/redmine/issues/111822 Original Date: 2023-01-23
Given an evaluation that requires a lagged persistence source When I want to declare persistence as having a constant duration (e.g., the value ending PT24H prior to the reference time of a forecast or the valid time of a simulation) Then I should be able to declare the duration, rather than an order So that I can have a persistence baseline that has a guaranteed/consistent interpretation for every persistence time-series created