Karl, how do you deal with the type axis in a practical manner? How does one select a particular 'type' axis value for plotting ?
I see there is no "type" coordinate variable, so the landCoverFrac:coordinates = "type_description" attribute is used for treating that dimension. Regards, Etienne On Mon, Jun 4, 2012 at 3:08 PM, Karl Taylor <[email protected]> wrote: > Dear Etienne, Jonathan, and all, > > For CMIP5, I've ncdumped below some of the information in the Plant > Functional Type Grid Fraction". We asked the groups to include a precise > description of the plant function type in a variable named > "type_description", but this is not standardized. Note that the coordinate > "type" is a simple index and again is not standardized across models. > > regards, > Karl > ncdump landCoverFrac_Lmon_MPI-ESM-LR_1pctCO2_r1i1p1_199001-199912.nc | more > netcdf landCoverFrac_Lmon_MPI-ESM-LR_1pctCO2_r1i1p1_199001-199912 { > dimensions: > time = UNLIMITED ; // (120 currently) > type = 13 ; > lat = 96 ; > lon = 192 ; > bnds = 2 ; > strlen = 34 ; > variables: > double time(time) ; > time:bounds = "time_bnds" ; > time:units = "days since 1850-1-1 00:00:00" ; > time:calendar = "proleptic_gregorian" ; > time:axis = "T" ; > time:long_name = "time" ; > time:standard_name = "time" ; > double time_bnds(time, bnds) ; > char type_description(type, strlen) ; > type_description:long_name = "plant functional type" ; > type_description:standard_name = "area_type" ; > double lat(lat) ; > lat:bounds = "lat_bnds" ; > lat:units = "degrees_north" ; > lat:axis = "Y" ; > lat:long_name = "latitude" ; > lat:standard_name = "latitude" ; > double lat_bnds(lat, bnds) ; > double lon(lon) ; > lon:bounds = "lon_bnds" ; > lon:units = "degrees_east" ; > lon:axis = "X" ; > lon:long_name = "longitude" ; > lon:standard_name = "longitude" ; > double lon_bnds(lon, bnds) ; > float landCoverFrac(time, type, lat, lon) ; > landCoverFrac:standard_name = "area_fraction" ; > landCoverFrac:long_name = "Plant Functional Type Grid > Fraction" ; > landCoverFrac:comment = "The categories may differ from > model to model, depending on their PFT definitions. This may include > natural PFTs, anthropogenic PFTs, bare soil, lakes, urban areas, etc. Sum > of all should equal the fraction of the grid-cell > that is land." ; > landCoverFrac:units = "%" ; > landCoverFrac:cell_methods = "time: mean" ; > landCoverFrac:cell_measures = "area: areacella" ; > landCoverFrac:history = "2011-06-01T05:07:12Z altered by > CMOR: replaced missing value flag (1e+22) with standard missing value > (1e+20)." ; > landCoverFrac:missing_value = 1.e+20f ; > landCoverFrac:_FillValue = 1.e+20f ; > landCoverFrac:associated_files = "baseURL: > http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: > gridspec_land_fx_MPI-ESM-LR_1pctCO2_r0i0p0.nc areacella: > areacella_fx_MPI-ESM-LR_1pctCO2_r0i0p0.nc" ; > landCoverFrac:coordinates = "type_description" ; > > // global attributes: > :institution = "Max Planck Institute for Meteorology" ; > :institute_id = "MPI-M" ; > :experiment_id = "1pctCO2" ; > :source = "MPI-ESM-LR 2011; URL: > http://svn.zmaw.de/svn/cosmos/branches/releases/mpi-esm-cmip5/src/mod; > atmosphere: ECHAM6 (REV: 4571), T63L47; land: JSBACH (REV: 4571); ocean: > MPIOM (REV: 4571), GR15L40; sea ice: 4571; marine bgc: HAMOCC (REV: 4571);" > > :model_id = "MPI-ESM-LR" ; > :forcing = "N/A" ; > :parent_experiment_id = "piControl" ; > :parent_experiment_rip = "r1i1p1" ; > :branch_time = 10957. ; > :contact = "[email protected]" ; > :history = "Model raw output postprocessing with modelling > environment (IMDI) at DKRZ: URL: > http://svn-mad.zmaw.de/svn/mad/Model/IMDI/trunk, REV: 3208 > 2011-06-01T05:07:12Z CMOR rewrote data to comply with CF standards and CMIP5 > requirements." ; > :references = "ECHAM6: n/a; JSBACH: Raddatz et al., 2007. > Will the tropical land biosphere dominate the climate-carbon cycle feedback > during the twenty first century? Climate Dynamics, 29, 565-574, doi > 10.1007/s00382-007-0247-8; MPIOM: Marsland et al., > 2003. The Max-Planck-Institute global ocean/sea ice model with orthogonal > curvilinear coordinates. Ocean Modelling, 5, 91-127; HAMOCC: > http://www.mpimet.mpg.de/fileadmin/models/MPIOM/HAMOCC5.1_TECHNICAL_REPORT.pdf;"; > ; > :initialization_method = 1 ; > :physics_version = 1 ; > :tracking_id = "91871851-f604-400d-a473-10ebc3a98638" ; > :product = "output" ; > :experiment = "1 percent per year CO2" ; > :frequency = "mon" ; > :creation_date = "2011-06-01T05:07:12Z" ; > :Conventions = "CF-1.4" ; > :project_id = "CMIP5" ; > :table_id = "Table Lmon (27 April 2011) > c4244dce0826a43bb0b259f293e2f742" ; > :title = "MPI-ESM-LR model output prepared for CMIP5 1 > percent per year CO2" ; > :parent_experiment = "pre-industrial control" ; > :modeling_realm = "land" ; > :realization = 1 ; > :cmor_version = "2.5.9" ; > data: > > . > . > . > . > > > type_description = > "glacier ", > "tropical broadleaf evergreen trees", > "tropical broadleaf deciduous trees", > "extra-tropical evergreen trees ", > "extra-tropical deciduous trees ", > "raingreen shrubs ", > "deciduous shrubs ", > "C3grass ", > "C4grass ", > "C3 pasture ", > "C4 pasture ", > "C3crops ", > "C4crops " ; > > . > . > . > . > > > > > > > > On 6/4/12 10:17 AM, Jonathan Gregory wrote: > > Dear Etienne > > I think the structure you have adopted for the data is fine. > > double pft(pft) ; > pft:long_name = "plant functional type" ; > pft:units = "none" ; > > double npp(time, pft, latitude, longitude) ; > npp:long_name = "npp of carbon for each pft" ; > npp:units = "kg m-2 year-1" ; > > The specific problem you raise is concerned with the axis attribute. That > attribute is really intended for identifying spatiotemporal coordinates; > although it may be convenient, it is redundant because they can also be > identified in other ways. It has not been extended for non-spatiotemporal > axes like pft. In your CDL, the pft axis is identified by its long_name. > To make this more reliable, you might want to use a standard_name for this > pft coordinate variable. There isn't such a standard_name at present, but > area_type is often vegetation type in practice, so you could perhaps use > that. We could standardise new area_types by proposals to this email list. > > Also, there is the new proposal, which I expect will go into the > standard_name table, for UN/FAO land cover types, which in many cases are > also vegetation types. > See http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2012/033507.html > > The quantities identified by these standard_names are string-valued, whereas > you expect a numeric pft. However, a string-valued one could be encoded as a > number by using the flag_values and flag_meanings attributes. > > There is an existing standard name for NPP as well viz > net_primary_productivity_of_carbon (kg m-2 s-1) > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
