Support for CFTime.DateTimeNoLeap calendar

[BSchilperoort]

Feature type

Changing existing functionality

Improvement Description

The current supported calendar types of forcing data seem to be CFTime.DateTimeJulian, CFTime.DateTimeProlepticGregorian, CFTime.DateTimeStandard. However, the CFTime.DateTimeNoLeap calendar is not supported.

Many global climate models use this "noleap" calendar, so it would be nice to be able to use the data from those without a tricky conversion.

On this line the following error is raised:

JuliaError: MethodError: Cannot `convert` an object of type CFTime.DateTimeNoLeap to an object of type Dates.DateTime

Closest candidates are:
  convert(::Type{Dates.DateTime}, !Matched::T2) where T2<:Union{CFTime.DateTimeJulian, CFTime.DateTimeProlepticGregorian, CFTime.DateTimeStandard}

Additional Context

I encountered this issue while trying to generate forcing data for Wflow.jl with eWaterCycle + ESMValTool.

[JoostBuitink]

We actually do support using different calendar types (all CF convention calendars), and have run Wflow with different types of calendars. However, in order to make sure this works, you need to specify the calendar type in your toml file. See this page in the documentation for some additional explanations.

In your case, it should be calendar = "noleap" or calendar = "365_day". See this page for the different calendar options: https://cfconventions.org/cf-conventions/cf-conventions.html#calendar

Hopefully this solves your issue!

[BSchilperoort]

Hi Joost, thanks for your reply. I have actually set the calendar to "noleap" already in the config file, however it does not work.
Setting it to "365_day" produces the exact same error as I outlined in the first post.

Here's the start of the config file:

casename = "wflow_sbm"
calendar = "noleap"
starttime = "1990-01-01T00:00:00"
endtime = "1990-12-31T00:00:00"
time_units = "days since 1900-01-01 00:00:00"
timestepsecs = 86400

I run the model through the BMI, however I am not sure if that matters in this case.

[BSchilperoort]

Looking at the CFTime.jl package, the convert function is quite limited in the calendar types it accepts.

To be able to convert from a noleap calendar, the reinterpret function has to be used.

[JoostBuitink]

And how is the time dimension setup in your forcing file? I have ran Wflow in the past with 365_day (and 360_day) calendar without issue. The time dimension in my forcing dataset looks like this (opened with xarray):

array([cftime.DatetimeNoLeap(1970, 1, 1, 0, 0, 0, 0, has_year_zero=True),
       cftime.DatetimeNoLeap(1970, 1, 2, 0, 0, 0, 0, has_year_zero=True),
       cftime.DatetimeNoLeap(1970, 1, 3, 0, 0, 0, 0, has_year_zero=True), ...,
       cftime.DatetimeNoLeap(2014, 12, 29, 0, 0, 0, 0, has_year_zero=True),
       cftime.DatetimeNoLeap(2014, 12, 30, 0, 0, 0, 0, has_year_zero=True),
       cftime.DatetimeNoLeap(2014, 12, 31, 0, 0, 0, 0, has_year_zero=True)],
      dtype=object)

[BSchilperoort]

What it looks like in xarray depends a bit on which packages you have installed
This is the info from ncdump

	double time(time) ;
		time:axis = "T" ;
		time:bounds = "time_bnds" ;
		time:units = "days since 1850-1-1 00:00:00" ;
		time:standard_name = "time" ;
		time:long_name = "time" ;
		time:calendar = "365_day" ;
		time:calendar_type = "noleap" ;
		time:cartesian_axis = "T" ;

The data has been generated using ESMValTool, so it should adhere to the CF-1.7 and CMOR standards

---

If I change the following line

Wflow.jl/src/io.jl

Line 268 in ac78c32

time = convert(eltype(dataset_times), clock.time)

to:

        time = reinterpret(eltype(dataset_times), clock.time)

the model runs fine with the noleap calendar.

[verseve]

Hi Bart, could you please share your model case, so we can reproduce the issue?

[BSchilperoort]

Hi Willem. I have been trying to reproduce the error however I am not encountering it anymore...

I am now able to provide the model with a noleap calendar, and run it without any issues. I'll close this issue now, if I encounter the error again I will reopen it. Thanks!