Reading a netcdf file with time dimension of length 1

[hol430]

Hi @MagicForrest! I'm using the package to read a CF-compliant (as far as I know) netcdf file which has a time dimension of length 1. When I call getField() on this file, I get the following error from getField_NetCDF():

Error in if (mean.timestep.differences >= 28 & mean.timestep.differences <=  : 
  missing value where TRUE/FALSE needed

This is because mean.timestep.differences is NA in this case (it is effectively mean(diff(c(0)))). A quick workaround that appears to work for me is to add an extra branch to the if statement on the line giving the error, which detects the presence of such a single-value time axis (e.g. if (length(all.time.intervals) == 1)). However, I'm not sure how comprehensive this solution would be (I haven't looked closely enough at this function to fully understand it and maybe this "solution" only fixes files with "days since" units).

A better longterm solution to this problem might be to use the CFtime package to handle the parsing of dates for us. This package lets you do something like this:

nc <- nc_open(input_file)
calendar <- ncatt_get(nc, "time", "calendar")$value
units <- ncatt_get(nc, "time", "units")$value
values <- ncvar_get(nc, "time")
dates <- as.Date(as_timestamp(CFtime(units, calendar, values)))

That said, I haven't looked too closely at the current time-reading code, so maybe there's some extra logic in there that we need, or there are some other edge cases I haven't thought about.

[MagicForrest]

Hi @hol430! Don't look too closely at the time-reading code, it is a masterclass in madness! Although to be fair parsing netCDF time axes is pretty tricky thing, and the code generally does okay. But you did find a weak spot.

Replacing it would indeed be a good idea. It would be more maintainable in the long run, provided that CFtime is maintained. I think one extra dependency is worth it. However, it actually still doesn't get away from the problem. At some point we still need a line like the one that failed to look at the interval of the dates and decide if the data should be considered monthly or daily since DGVMTools makes that distinction in quite a fundamental way. Arguably that wasn't the best design choice, but it does have some advantages, and that would be a huge overhaul to change. Unless CFtime has the functionality to guess the resolution of the data, but I couldn't see it.

So for now I favour the if-statement approach that you suggested, but a larger overhaul of the NetCDF reading code would be a good idea.

[hol430]

Oh true, I hadn't thought about what DGVMTools might need beyond the raw date/time values. Refactoring this code to use CFtime (and then testing it!) would be quite a bit of work I'd imagine, so makes sense to improve the existing solution in the short term.

I'm happy to submit a PR if you want, although I can't promise that my "solution" won't also have a bit of madness in it!