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
Description of bug
For monthly average data, it is not uncommon for time indices to be on the middle day of the month, which varies from month the month. This breaks the logic in return_time_series_freq, which only picks out a monthly frequency if the time index day is the same for each month.
I encountered the issue while attempting to generate an uninitialized forecast. I think it was likewise causing silent issues in generating a persistence forecast, which was previously producing NaNs but works fine after implementing a hack (changing the time index of the verification dataset to match what's expected).
Code sample (reproducing the core logic of return_time_series_freq)
import cftime
# monthly separated time array
times = [cftime.DatetimeNoLeap(1,1,15),cftime.DatetimeNoLeap(1,2,14),cftime.DatetimeNoLeap(1,3,15)]
ds = xr.Dataset(coords={'time':times})
for freq in ['day','month','year']:
# first dim values not equal all others
if not (
getattr(ds.isel({'time': 0})['time'].dt, freq) == getattr(ds['time'].dt, freq)
).all():
print(freq)
break
This returns a frequency of "day", which results in subsequent errors. To work around this, a user has to manipulate at least the verification dataset to have the same "day" for each month in the time index.
Would it be undesirable for the frequency of the verification dataset to be user specified in the same way as the units of the initialized dataset lead time need to be specified?
Usually I went for "changing the time index of the verification dataset to match what's expected" ie fixing before using climpred. Mostly going for beginning of the month to just have 1s.
Not sure how difficult a change would be to implement but feel free.
Description of bug
For monthly average data, it is not uncommon for time indices to be on the middle day of the month, which varies from month the month. This breaks the logic in
return_time_series_freq
, which only picks out a monthly frequency if the time index day is the same for each month.I encountered the issue while attempting to generate an
uninitialized
forecast. I think it was likewise causing silent issues in generating a persistence forecast, which was previously producing NaNs but works fine after implementing a hack (changing the time index of the verification dataset to match what's expected).Code sample (reproducing the core logic of
return_time_series_freq
)This returns a frequency of "day", which results in subsequent errors. To work around this, a user has to manipulate at least the verification dataset to have the same "day" for each month in the time index.
Would it be undesirable for the frequency of the verification dataset to be user specified in the same way as the units of the initialized dataset lead time need to be specified?
Output of
climpred.show_versions()
The text was updated successfully, but these errors were encountered: