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.

Tips on using NetCDF files with GrADS
Courtesy of Jennifer Adams, IGES/COLA.

Additional documentation may be found here: http://www.iges.org/grads/gadoc/gradcomdsdfopen.html
http://www.iges.org/grads/gadoc/gradcomdxdfopen.html
http://www.iges.org/grads/gadoc/descriptorfile.html

Questions related to the GFDL CM2.x models may be directed to…