Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

start date for time variable in CCSM output

C

carlos@klamathconservation_org

New Member
I am involved in a research project modeling habitat and population viability for lynx in the northeastern US and southeastern Canada and would like to incorporate the effects of climate change (specifically, change in annual snowfall) into my future threat scenarios for lynx.
I found the GIS output available from www.gisclimatechange.org very helpful but am now attempting to use netcdf files from earthsystemgrid.org because the t85_gx1v3 output seems to provide higher resolution and access to a greater variety of scenarios. But I have not found documentation on how to interpret the time variable, for example, if I want output for the year 2050, how do I interpret the time variable units given in the netCDF files: e.g., "days since 0400-01-01", or the naming convention of the .nc files: year 400 equals what year A.D.? Thanks for any help or a link to more complete documentation on model parameters.
 
S

strandwg

Moderator
Staff member
The specification of time in netCDF files isn't real straightforward, but it does make sense.

Basically, the "units" attribute of the time coordinate variable specifies the time origin and the units of measure. Each value of the time coordinate value can be considered to be a "delta-t" from that origin, and can be used to calculate a calendar date for a given time coordinate value. I use some Fortran code I've written to do so for my own use; most netCDF-aware software packages can do the calculation to translate the time variable value into a more-commonsense year-month-day format. There is also the attribute "calendar", which specifies what calendar is to be used. For all CCSM model runs, the calendar is fixed at 365 days per year - i.e., February always has 28 days; there are no leap years, and so "calendar" has the attribute "noleap".

To be more specific, suppose I have a CCSM netCDF file with the following relevant information (seen using 'ncdump'):

double time(time) ;
time:calendar = "noleap" ;
time:standard_name = "time" ;
time:axis = "T" ;
time:units = "days since 0000-1-1" ;
time:long_name = "time" ;

and

time = 730015.5, 730045, 730074.5, 730105, 730135.5, 730166, 730196.5, 730227.5, 730258, 730288.5, 730319, [...]

Using the time:units and time:calendar attributes, and the values of the time coordinate variable, I can determine, using my "print_nc_time" Fortran code, that the time values of the netCDF file are as follows:

prompt> print_nc_time netcdf_file.nc
tval = 730015.50 yyyy/mm/dd=2000/01/16 (2000/01/01-2000/02/01) [ 1]
tval = 730045.00 yyyy/mm/dd=2000/02/15 (2000/02/01-2000/03/01) [ 2]
tval = 730074.50 yyyy/mm/dd=2000/03/16 (2000/03/01-2000/04/01) [ 3]
tval = 730105.00 yyyy/mm/dd=2000/04/16 (2000/04/01-2000/05/01) [ 4]
tval = 730135.50 yyyy/mm/dd=2000/05/16 (2000/05/01-2000/06/01) [ 5]
tval = 730166.00 yyyy/mm/dd=2000/06/16 (2000/06/01-2000/07/01) [ 6]
tval = 730196.50 yyyy/mm/dd=2000/07/16 (2000/07/01-2000/08/01) [ 7]
tval = 730227.50 yyyy/mm/dd=2000/08/16 (2000/08/01-2000/09/01) [ 8]
tval = 730258.00 yyyy/mm/dd=2000/09/16 (2000/09/01-2000/10/01) [ 9]
tval = 730288.50 yyyy/mm/dd=2000/10/16 (2000/10/01-2000/11/01) [ 10]
tval = 730319.00 yyyy/mm/dd=2000/11/16 (2000/11/01-2000/12/01) [ 11]

I happen to know a priori that the file in question consists of monthly average values, so the time index specifically refers to the middle of the month, and the time "edges" are at the beginning and ending of that same month.

There are a couple of things that complicate the matter a little bit. CCSM netCDF files directly from the atmosphere model, as I believe you are retrieving from ESG, are a little quirky in that the time coordinate values end up being calculated as the 1st of a given month, but it actually represents the month average of the previous month. This means you have to be a little careful about how you interpret the time values. It's easy to forget that a time value that represents (say) "2050/01/01" actually means the average of December 2049.

One other thing to note is that model time is not strictly the same as the common calendar we use - the months of the year are correct climatologically speaking, and the years do represent years of model time, but a time value that works out to be "July 2080" doesn't quite mean "July 2080 A.D.". What I mean here is that the model is typically run for an extended period of model time (on the order of 1000 years) with forcings that vary over the course of the 12 calendar months, but not from year to year - what we call a "control" run. Then, once the model is determined to be in a quasi-equilibrated state, we then change the forcings (greenhouse gasses [CO2, methane, etc], solar irradiance, suflate aerosol, etc.) to approximations of real-world values, that do change from month to month and year to year, and we somewhat arbitrarily assign the beginning of such a run to be 1 January 1870. It's January, but the "1870" part is not "1870 A.D.". The upshot is that "July 2080" means 210 years and 6 months after the beginning of the run, not literally the July 2080 of the calendar we use day-to-day.

If you have any additional questions, please feel free to ask. Like I mentioned, the whole issue of time in coupled climate models, and its representation in the netCDF files that are available for analysis, require a little thought to make sense.
 
You must log in or register to reply here.
Top