Time variable not CF-compliant

[matthewhoffman]

The way MPAS handles time, is not CF compliant. The xtime string cannot easily be parsed by many tools.

A CF-compliant solution was summarized by @czender:

The solution is to use CF-compliant
time coordinate much like CAM does. It's a numeric
(not string) -valued coordinate with a UDUnits
"time_elements since base_time" units attribute, and
an optional "calendar" attribute, and an optional
"bounds" variable (both highly recommended),
e.g.,

zender@aerosol:~/data/ne30/raw$ ncks -v time ${DATA}/ne30/raw/famipc5_ne30_v0.3_00007.cam.h1.2001-01-01-00000.nc
netcdf famipc5_ne30_v0.3_00007.cam.h1.2001-01-01-00000 {
dimensions:
nbnd = 2 ;
time = UNLIMITED ; // (30 currently)

variables:
double time(time) ;
time:long_name = "time" ;
time:units = "days since 2001-01-01 00:00:00" ;
time:calendar = "noleap" ;
time:bounds = "time_bnds" ;

double time_bnds(time,nbnd) ;
time_bnds:long_name = "time interval endpoints" ;

data:
time = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29 ;

time_bnds =
0, 0,
0, 1,
1, 2,
2, 3,
3, 4,
4, 5,
5, 6,
6, 7,
7, 8,
8, 9,
9, 10,
10, 11,
11, 12,
12, 13,
13, 14,
14, 15,
15, 16,
16, 17,
17, 18,
18, 19,
19, 20,
20, 21,
21, 22,
22, 23,
23, 24,
24, 25,
25, 26,
26, 27,
27, 28,
28, 29 ;

} // group /

These can easily be converted to legible dates by, e.g.,

zender@aerosol:~/data/ne30/raw$ ncks --cal -v time ${DATA}/ne30/raw/famipc5_ne30_v0.3_00007.cam.h1.2001-01-01-00000.nc
netcdf famipc5_ne30_v0.3_00007.cam.h1.2001-01-01-00000 {
dimensions:
nbnd = 2 ;
time = UNLIMITED ; // (30 currently)

variables:
double time(time) ;
time:long_name = "time" ;
time:units = "days since 2001-01-01 00:00:00" ;
time:calendar = "noleap" ;
time:bounds = "time_bnds" ;

double time_bnds(time,nbnd) ;
time_bnds:long_name = "time interval endpoints" ;

data:
time = "2001-01-01", "2001-01-02", "2001-01-03", "2001-01-04", "2001-01-05", "2001-01-06", "2001-01-07", "2001-01-08", "2001-01-09", "2001-01-10", "2001-01-11", "2001-01-12", "2001-01-13", "2001-01-14", "2001-01-15", "2001-01-16", "2001-01-17", "2001-01-18", "2001-01-19", "2001-01-20", "2001-01-21", "2001-01-22", "2001-01-23", "2001-01-24", "2001-01-25", "2001-01-26", "2001-01-27", "2001-01-28", "2001-01-29", "2001-01-30" ;

time_bnds =
"2001-01-01", "2001-01-01",
"2001-01-01", "2001-01-02",
"2001-01-02", "2001-01-03",
"2001-01-03", "2001-01-04",
"2001-01-04", "2001-01-05",
"2001-01-05", "2001-01-06",
"2001-01-06", "2001-01-07",
"2001-01-07", "2001-01-08",
"2001-01-08", "2001-01-09",
"2001-01-09", "2001-01-10",
"2001-01-10", "2001-01-11",
"2001-01-11", "2001-01-12",
"2001-01-12", "2001-01-13",
"2001-01-13", "2001-01-14",
"2001-01-14", "2001-01-15",
"2001-01-15", "2001-01-16",
"2001-01-16", "2001-01-17",
"2001-01-17", "2001-01-18",
"2001-01-18", "2001-01-19",
"2001-01-19", "2001-01-20",
"2001-01-20", "2001-01-21",
"2001-01-21", "2001-01-22",
"2001-01-22", "2001-01-23",
"2001-01-23", "2001-01-24",
"2001-01-24", "2001-01-25",
"2001-01-25", "2001-01-26",
"2001-01-26", "2001-01-27",
"2001-01-27", "2001-01-28",
"2001-01-28", "2001-01-29",
"2001-01-29", "2001-01-30" ;

} // group /

[xylar]

I fully support (and would happily contribute to) any effort to address this issue. The non-CF-compliant time issue has been a big headache in MPAS-Analysis, up there with not having a _FillValue attribute (#1380).

[matthewhoffman]

Discussion on 2/26/18: Consider making this a framework streams capability that automatically adds the CF-compliant time variable to output streams. However, it also appears possible to leave this up to each core, using existing Registry capabilities. Having a standard implementation in framework would seem more convenient, but it may preclude core-specific choices about the origin time and bounds.