[ISSUE] HEMCO cannot read data using a 365-day calendar

[cdholmes]

Describe the bug:

HEMCO doesn't correctly handle time variables that use a No-Leap-Year (i.e. 365 day calendar). CEDS version 2021-04-21 emissions are distributed in netCDF files that use a 365-day calendar and "days since 1750" for the time variable. HEMCO seems to treat the date as if it were using a Gregorian calendar with leap years. By year 2000, there's about a two-month offset between the Gregorian and 365-day calendars, so HEMCO uses the wrong month.

Here's the time variable definition from the NetCDF file. double time(time) ; time:units = "days since 1750-01-01 0:0:0" ; time:long_name = "time" ; time:calendar = "365_day" ; time:axis = "T" ; time:bounds = "time_bnds" ; time:realtopology = "linear" ; time:standard_name = "time" ;

Solution

I can rewrite the time variable for this file, but this was a tough bug to find, so it would be nice to save others the trouble.

It would be nice if HEMCO could read this kind of time variable, but, if that's not feasible, I think it would be better for HEMCO to halt with an error rather than silently proceed with time variable that it can't properly read.

Your HEMCO version and runtime environment:

HEMCO 3.4 in GEOS-Chem 13.4

[yantosca]

Thanks @cdholmes for bringing this up. We will take a look into this but it might take us a while.

We have been recommending that data files have the first time in the file match the reference date (this lessens the chance of encountering errors with GCHP. It might be easier to just reprocess the data with

cdo setreftime,YYYY-MM-DD,00:00:00 myfile.nc tmp.nc
mv tmp.nc myfile.nc

where YYYY-MM-DD is the first time in the file.

Also tagging @msulprizio @jimmielin @christophkeller

[lizziel]

I checked in with GMAO on whether MAPL is able to handle a 365-day calendar in an input file. It is not, and neither is ESMF. The ESMF docs include this as future work:

41.4 Restrictions and Future Work ... Calendar date conversions. Date conversions are currently defined between the Gregorian, Julian, Julian Day, and Modified Julian Day calendars. Further research and work would need to be done to determine conversion algorithms with and between the other calendars: No Leap, 360 Day, and Custom.

I agree with @yantosca that conversion to a more standard calendar prior to using in GEOS-Chem is the easiest way forward.

[cdholmes]

Thanks for looking into this. I've already done the conversion to a standard calendar for my input file. For reference the cdo command to change the calendar is

cdo setcalendar,standard ifile ofile

Changing the reference time won't fix the issue as the calendar will still use 365-day years.

I agree that there is no urgency to add support for these less common calendars in HEMCO. In the meantime, I think it's worth considering adding an if statement to HEMCO that raises an error when it encounters one of these calendars that it can't read properly. These 365 and 360-day calendars are more common in the climate modeling community, so I expect this issue will arise again as HEMCO is deployed in other models and as GEOS-Chem uses CMIP datasets.

You can close this issue as far as I'm concerned.

[yantosca]

Thanks @cdholmes for the tip about setcalendar. I can add that to the documentation for the "Work with netCDF files" guide. I'll also try to add an error trap for the calendar. Closing this issue out now.

[lizziel]

I also put in a feature request with GMAO to give an error if a file calendar is encountered that is not supported. Regarding the conversion to a different calendar, at least for the case of CEDS the simplest way would be to change the file reference time to be start date of data in the file and adjust the values accordingly so that they start at zero. Then add in a leap day for leap years. If needed the data could be redistributed across a new set of files, e.g. monthly or annual or even daily, if they are not already.