DayMet NCDF - Unequal Timestep Error
Posted: Thu Sep 29, 2022 3:04 pm
Hi there,
I'm attempting to run UBCWM with gridded forcing data from Daymet, however I encounter the following error:
###########################
ERROR : GetTimeInfoFromNetCDF: time steps are not equal in NetCDF input
###########################
I acquired the Daymet data through the "daymetr" R package for a couple decades. I then stitched the annual .nc files together using the "ncecat" command in NCO.
The resultant .nc files (separate files precip, min temp, max temp, srad) each have identical time dimensions as follows (from Panoply):
######################
float time(time=9855);
:standard_name = "time";
:long_name = "24-hour day based on local time";
:units = "days since 1950-01-01 00:00:00";
:calendar = "standard";
:axis = "T";
###########################
The timesteps in the .nc files appears complete for the sequence 16436.5 to 26297.5
I don't get the sense that the 0.5 decimals would create issues.. The only issue I can see is that the calendar is "standard" when Daymet states it uses a 365 day calendar. When I have adjusted this (both in .rvi and .nc) it has not resolved the time length error.
Am I missing something here? Does the error reflect issues with the actual timestamps, or with the .nc metadata?
Many thanks,
Jeremy
I'm attempting to run UBCWM with gridded forcing data from Daymet, however I encounter the following error:
###########################
ERROR : GetTimeInfoFromNetCDF: time steps are not equal in NetCDF input
###########################
I acquired the Daymet data through the "daymetr" R package for a couple decades. I then stitched the annual .nc files together using the "ncecat" command in NCO.
The resultant .nc files (separate files precip, min temp, max temp, srad) each have identical time dimensions as follows (from Panoply):
######################
float time(time=9855);
:standard_name = "time";
:long_name = "24-hour day based on local time";
:units = "days since 1950-01-01 00:00:00";
:calendar = "standard";
:axis = "T";
###########################
The timesteps in the .nc files appears complete for the sequence 16436.5 to 26297.5
I don't get the sense that the 0.5 decimals would create issues.. The only issue I can see is that the calendar is "standard" when Daymet states it uses a 365 day calendar. When I have adjusted this (both in .rvi and .nc) it has not resolved the time length error.
Am I missing something here? Does the error reflect issues with the actual timestamps, or with the .nc metadata?
Many thanks,
Jeremy