What type of calendar is used in the CM2.x experiments? A 365 day calendar is used. February always has 28 days and a year always has 365 days.
(NOTE: This answer applies to all CM2.x deccen experiments.)
Coupled climate model experiments conducted at GFDL to explore deccen climate issues have traditionally used a 365 day calendar without leap years. Neglecting leap days (i.e., 29 February never occurs) is acceptable for these experiments because no attempt is being made to replicate the weather conditions of any particular day. Also, by having a calendar in which a year is always 365 days in length, many analyses of the long model-produced time series become more straightforward, because the seasonal cycle is identical each and every year e.g., the location of the sun in the sky at 12Z on 7 October – or any other date and time – is exactly the same every year.)
That the CM2.x models use a 365 day calendar is indicated in the netCDF output file attributes as…
time:calendar = "noleap" ;
The NetCDF Climate and Forecast (CF) Metadata Conventions provide for not one, but two ways to specify a 365 day repeating calendar. The two are “noleap” or “365_day”. The CM2.x model output uses the “noleap” attribute setting. (A “common_year” also is considered to be 365 days.)
So, what does this mean for the end user? It depends upon what analysis package is being used.
Analysis programs that have adopted the CF calendar conventions should recognize that CM2.x is using a noleap calendar and automatically adapt, without any user actions required. [For example, the Ferret analysis program correctly handles the CM2.x noleap calendar, requiring no user actions in order for the calendar to be properly displayed.]
Some other programs are able to accommodate a noleap calendar, but only if the user intervenes. Such programs do not recognize the noleap netCDF attributes, and instead require the user to somehow specify the kind of calendar being used. [For example, the GrADS analysis program can adapt to the noleap calendar if one creates a partial descriptor file and uses the “xdfopen” command. For more information about dealing with the noleap calendar in GrADS, see the Tips on using NetCDF files with GrADS writeup at the bottom of this page, provided courtesy of Jennifer Adams of COLA.]
However, programs that neither recognize the noleap attribute, nor allow one to override the default calendar, will have problems displaying the proper date if the program assumes anything other than a 365 day calendar.
How bad a mistake is made if one assumes the CM2.x models use a Gregorian or standard calendar (i.e., one with leap days) instead of a noleap calendar? It depends on how far in time the point of interest is relative to the reference time the program uses in its calendar calculations. For example, consider the case where the reference time is equivalent to the specification
time:units = "days since 1-01-01 00:00:00" ;
In other words, the calendar calculations use 1 January year 1 as a starting point. If one looks at a January mean of year 451 produced by a CM2.x experiment while using a program that does its calculations using a noleap 365 day calendar, the date will appear as 16 Jan 451. But, a program that bases its calculations on a calendar that includes leap days will show the date as being sometime in September of year 450. Over 451 years, more than 100 leap days would have accumulated, leading to a multi-month offset in the calendar calculation.
Use the ‘sdfopen’ command — This is the simplest because the users do no need to provide anything more than a file name. GrADS checks all the attribute metadata in the file to determine how to place the data into a lat/lon/lev/time grid context inside GrADS. For the time axis, this is done by reading the first two data values, determining a ‘start’ and ‘increment’ and calculating the remainder. Unfortunately, when the time axis units are (for example) ‘hours since 1980-01-01 00:00:00″ and the first two values are 2453544 and 2454216, the calculation of the dates associated with these two large integers is done using a gregorian calendar, not a 365-day NOLEAP calendar, even if that calendar attribute exists in the data file. So, the initial date and the increment may well be incorrect, and thus the time axis values will not be correct when this type of data file is opened with ‘sdfopen’
Use the ‘xdfopen’ command — This command is one step up from the ‘sdfopen’ procedure. The user is required to construct a partial descriptor file, one that provides only that metadata that is missing or inadequate for GrADS to figure out how to place the data into its internal lat/lon/lev/time grid. In the case of a 365-day NOLEAP data file, all that is needed is a DSET and a TDEF entry to provide the data file name and the correct time axis start and increment values. For example, a descriptor file to use with the ‘xdfopen’ command might look like this:
Use the ‘open’ command — This command requires the user to provide all the metadata that GrADS needs in a full-blown descriptor file. No attribute metadata is gathered from the data file itself. The descriptor file for the above example data file might look like this:
Option #1 will not work reliably with 365-day NOLEAP data files. Option #3 will only work with GrADS 1.9. Option #2 is the easiest and quickest. However if you plan to be templating (or aggregating) several netcdf files together, then it is worth the effort to write a full descriptor file and use option #3 — the use of ‘xdfopen’ with templated data sets is known to lead to memory leaks and eventual core dumps.