You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some indicators return day-of-year data. The values are thus constrained by the calendar of the input. A 360_day timeseries will have a maximal value of 360. When mixing data from different calendar, like when doing ensemble statistics, this introduces a bias in the statistics. For example, if all members agree that this event happens on the last day of the year, some will have 360, some will have 365 and some 366. The mean will be lower than 365, and the standard deviation will be non-zero, even though every model agrees.
Potential Solution
convert_calendar could detect day-of-year data through the is_dayofyear attribute that xclim adds on such cases.
The basic conversion could be : doy_out = out.time.dt.days_in_year * doy_in / doy_in.time.dt.day_in_year.
Additional context
Caveats:
This introduces floating point day of year, which might not be fully expected in some cases.
For 360_day calendar, this is equivalent to the align_on='year' timestamp conversion method. What about the align_on='date' ? That would need a mapping of doy values, not so complex, just a bit heavier. And should the user be able to decide on which method to use separately on the time coordinate and on the data?
is_dayofyear is xclim-specific. There is no CF standards about this, AFAIK. This would not be portable to xarray's convert_calendar.
Contribution
I would be willing/able to open a Pull Request to contribute this feature.
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
<!--Please ensure the PR fulfills the following requirements! -->
<!-- If this is your first PR, make sure to add your details to the
AUTHORS.rst! -->
### Pull Request Checklist:
- [x] This PR addresses an already opened issue (for bug fixes /
features)
- This PR fixes#1283
- [x] Tests for the changes have been added (for bug fixes / features)
- [x] (If applicable) Documentation has been added / updated (for bug
fixes / features)
- [x] CHANGES.rst has been updated (with summary of main changes)
- [x] Link to issue (:issue:`number`) and pull request (:pull:`number`)
has been added
### What kind of change does this PR introduce?
* New `convert_doy` function to convert the calendar reference of doy
data. Two options :
- "year" : doy is seen as the fraction of the year. I.e. : 360 in
`360_day` converts to 365 in `noleap`.
- "date" : doy is seen as a date (MM-DD). 360 in `360_day` converts to
364 in `noleap` (December 30th).
* Convert calendar can automatically apply `convert_doy` if its new
argument `doy=True` (or `doy='date'`).
* `convert_doy` will NOT convert the time coordinate.
### Does this PR introduce a breaking change?
No.
### Other information:
Addressing a Problem?
Some indicators return
day-of-year
data. The values are thus constrained by the calendar of the input. A360_day
timeseries will have a maximal value of 360. When mixing data from different calendar, like when doing ensemble statistics, this introduces a bias in the statistics. For example, if all members agree that this event happens on the last day of the year, some will have 360, some will have 365 and some 366. The mean will be lower than 365, and the standard deviation will be non-zero, even though every model agrees.Potential Solution
convert_calendar
could detectday-of-year
data through theis_dayofyear
attribute that xclim adds on such cases.The basic conversion could be :
doy_out = out.time.dt.days_in_year * doy_in / doy_in.time.dt.day_in_year
.Additional context
Caveats:
align_on='year'
timestamp conversion method. What about thealign_on='date'
? That would need a mapping of doy values, not so complex, just a bit heavier. And should the user be able to decide on which method to use separately on the time coordinate and on the data?is_dayofyear
is xclim-specific. There is no CF standards about this, AFAIK. This would not be portable toxarray
'sconvert_calendar
.Contribution
Code of Conduct
The text was updated successfully, but these errors were encountered: