DayMet NCDF - Unequal Timestep Error

[jmorris]

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

[jmorris]

Tested some more.

I've ran 365_day calendar mode using single point value from Daymet, trimmed the leap days off of my observed hydro data.

This warning came up:

#############
WARNING : CModelInitialize: if a non-standard calendar is used, care must be taken with forcing data. All gauge forcing data must use the same calendar convention. Mixed calendars are only supported for NetCDF forcing inputs.
################

So, if I were to use the NetCDF forcing data data (correcting the Daymet metadata to 365_day, as this is its actual calendar), and specifying :Calendar 365_day in my .rvi file... How would Raven know that if my observed hydro data is in gregorian? I don't see how this affects my original error, but I'm slowly learning that hydro modelling is an ever expansive challenge...

[jrcraig]

Hi jmorris,

The error "time steps are not equal in NetCDF input" indicates that consecutive time stamps in the .nc input file are separated by different durations, e.g, if you had consecutive time stamps 06:00 12:00 18:00 22:00, this would get flagged because it jumps from a time interval of 6 hours to one of 4 hours. Raven requires all data is evenly spaced in time. This most likely happened when stitching together the daymet data, as I believe the base daymet files do not have this problem.

It is important that you remove flow data corresponding to the lost leap days (I don't know if the best interpretation of daymet skips Feb 29 or Dec 31)

James

[jmorris]

Thanks James.

For future reference:

Daymet trims Dec 31 off each file, even though its metadata states a standard calendar. When I stitched them together, there were several Dec 31s missing during leap years.

My solution:

I still stitched the files together using NCO mergetime. Then opened .nc files in R, changed the calendar to "365_day", extracted the time variable and overwrote it with a continuous 365_day timestep sequence.

####################################################################

library(RNetCDF)
library(here)

fn <- here("Raven Models","test", "model","input","tmin_compiled.nc")

fo <- open.nc(fn, write = T)

# Best route - 365_day calendar -------------------------------------------

# re-establish the date sequence as 365 day years. shift dates back to account for missing leap dates.

# set 365_day calendar type
RNetCDF::att.put.nc(ncfile = fo, variable = "time", name = "calendar", type = "NC_CHAR", value = "365_day")
RNetCDF::att.get.nc(fo, "time", "calendar")

#get the time data
time <- RNetCDF::var.get.nc(fo, "time")

#create new continuous time seq
time.new <- seq(from = head(time, n = 1), to = as.vector(head(time, n = 1) + length(time) - 1), by = 1)

# put time.new as the new time stamps

var.put.nc(fo, "time", time.new)

close.nc(fo)

[jrcraig]

Thanks for providing your solution!