[CF-metadata] Composite area types in CMIP6 data

Jonathan Gregory j.m.gregory at reading.ac.uk
Mon Jan 9 10:14:09 MST 2017


Yes, that makes sense to me. J

On Mon, Jan 09, 2017 at 04:06:01PM +0000, Jones, Chris D wrote:
> Date: Mon, 9 Jan 2017 16:06:01 +0000
> From: "Jones, Chris D" <chris.d.jones at metoffice.gov.uk>
> To: "Gregory, Jonathan" <j.m.gregory at reading.ac.uk>
> CC: "martin.juckes at stfc.ac.uk" <martin.juckes at stfc.ac.uk>,
>  "taylor13 at llnl.gov" <taylor13 at llnl.gov>, "alison.pamment at stfc.ac.uk"
>  <alison.pamment at stfc.ac.uk>, "cf-metadata at cgd.ucar.edu"
>  <cf-metadata at cgd.ucar.edu>
> Subject: RE: Composite area types in CMIP6 data
> 
> Yes - I think that's exactly what we had in mind. But without losing the non-C3/C4 options too.
> 
> So we have a "tier-1" request, which simply asks for crop and pasture fraction. So we need cropFrac and pastureFrac variables
> 
> We then have a more detailed ("tier-2") request which breaks this down into more detail. So the same fraction is now split into pastureFracC3, pastureFracC4, cropFracC3 and cropFracC4.
> 
> Does that make sense?
> C
> 
> -- 
> Mr Chris Jones
> Head, Earth System and Mitigation Science Team
> Met Office Hadley Centre, FitzRoy Road, Exeter, EX1 3PB, U.K.
> Tel: +44 (0)1392 884514  Fax: +44 (0)1392 885681
> E-mail: chris.d.jones at metoffice.gov.uk  http://www.metoffice.gov.uk
> 
> -----Original Message-----
> From: Jonathan Gregory [mailto:j.m.gregory at reading.ac.uk] 
> Sent: 09 January 2017 15:51
> To: Jones, Chris D
> Cc: martin.juckes at stfc.ac.uk; taylor13 at llnl.gov; alison.pamment at stfc.ac.uk; cf-metadata at cgd.ucar.edu
> Subject: Re: Composite area types in CMIP6 data
> 
> Dear Chris
> 
> Right, so there are four cases. Would it be adequate and convenient for you to use four new area types
>   pastures|crops_of_c3|c4_plant_functional_types
> where by | I mean alternatives?
> 
> Best wishes
> 
> Jonathan
> 
> On Mon, Jan 09, 2017 at 01:10:41PM +0000, Jones, Chris D wrote:
> > Date: Mon, 9 Jan 2017 13:10:41 +0000
> > From: "Jones, Chris D" <chris.d.jones at metoffice.gov.uk>
> > To: "Gregory, Jonathan" <j.m.gregory at reading.ac.uk>,  
> > "martin.juckes at stfc.ac.uk" <martin.juckes at stfc.ac.uk>
> > CC: "taylor13 at llnl.gov" <taylor13 at llnl.gov>, "alison.pamment at stfc.ac.uk"
> >  <alison.pamment at stfc.ac.uk>, "cf-metadata at cgd.ucar.edu"
> >  <cf-metadata at cgd.ucar.edu>
> > Subject: RE: Composite area types in CMIP6 data
> > 
> > Hi All,
> > 
> > I think this might be over-complicating what we need. I don't think we need multi-dimensions here. We simply request that "pastureFrac" is sub-divided into C3 and C4. In the same we that we split trees into evergreen and deciduous etc.
> > 
> > So pastureFracC3 and pastureFracC4 can be the same structure as pastureFrac. They just have a different definition. The two should sum to give the total:
> > pastureFrac = pastureFracC3 + pastureFracC4
> > 
> > ditto for cropFrac and grassFrac
> > 
> > does that help?
> > 
> > (see figure 11 of the C4MIP paper: 
> > http://www.geosci-model-dev.net/9/2853/2016/ )
> > 
> > Cheers,
> > Chris
> > 
> > 
> > 
> > --
> > Mr Chris Jones
> > Head, Earth System and Mitigation Science Team Met Office Hadley 
> > Centre, FitzRoy Road, Exeter, EX1 3PB, U.K.
> > Tel: +44 (0)1392 884514  Fax: +44 (0)1392 885681
> > E-mail: chris.d.jones at metoffice.gov.uk  http://www.metoffice.gov.uk
> > 
> > -----Original Message-----
> > From: Jonathan Gregory [mailto:j.m.gregory at reading.ac.uk]
> > Sent: 08 January 2017 21:28
> > To: martin.juckes at stfc.ac.uk
> > Cc: taylor13 at llnl.gov; alison.pamment at stfc.ac.uk; Jones, Chris D; 
> > cf-metadata at cgd.ucar.edu
> > Subject: Re: Composite area types in CMIP6 data
> > 
> > Dear Martin
> > 
> > I agree with you. I think that it is consistent with the general CF approach that we should not introduce a new way of doing things when we have only one use-case. To solve this problem in hand, the easiest thing would be to add something like pastures_of_c4_plant_functional_types to the area_type table - just a simple addition to the lexicon with no structural change.
> > 
> > Best wishes
> > 
> > Jonathan
> > 
> > On Fri, Jan 06, 2017 at 05:52:52PM +0000, martin.juckes at stfc.ac.uk wrote:
> > > Date: Fri, 6 Jan 2017 17:52:52 +0000
> > > From: martin.juckes at stfc.ac.uk
> > > To: taylor13 at llnl.gov, j.m.gregory at reading.ac.uk
> > > CC: alison.pamment at stfc.ac.uk, chris.d.jones at metoffice.gov.uk, 
> > > cf-metadata at cgd.ucar.edu
> > > Subject: RE: Composite area types in CMIP6 data
> > > 
> > > Hello Karl, Jonathan,
> > > 
> > > before writing this email, I had a look at a CMIP5 variable using a similar coordinate, the variable "treeFracSecEver". That variable was provided by one institution (MIROC). I mention that, because I feel we should be cautious about extendin the convention in ways which commit us to a certain approach (because of the backward compatibility requirement of future changes) for a variable which can be described with the existing features and may not be used in the same form again.
> > > 
> > > I agree that there are many possible approaches, but, partly because of that, I don't agree that modifying the standard area type list of convention is "not a problem". It can be done, but it takes time -- and it is harder when the request is coming from outside the board. 
> > > 
> > > I'm happy to exploit any modifications to the area type list or convention that get approved, but, in the meantime I'd like to encode the request for these variables in a way which is consistent with the current rules of the CF convention. From my perspective, it would make sense to use the existing convention and look into a more structured encoding if there is a specific requirement for it. 
> > > 
> > > regards,
> > > Martin
> > > 
> > > ________________________________________
> > > From: Karl Taylor [taylor13 at llnl.gov]
> > > Sent: 06 January 2017 17:29
> > > To: Jonathan Gregory; Juckes, Martin (STFC,RAL,RALSP)
> > > Cc: Pamment, Alison (STFC,RAL,RALSP); 
> > > chris.d.jones at metoffice.gov.uk; cf-metadata at cgd.ucar.edu
> > > Subject: Re: Composite area types in CMIP6 data
> > > 
> > > Hi Martin and Jonathan,
> > > 
> > > An alternative would be to (generally) allow elemental area_types to 
> > > be combined with logical not/and/or connectors.  area_types are used 
> > > either as labels (stored in a variable pointed to by the coordinates
> > > attribute) or in cell_methods.  In both cases parsing combined types would be
> > > straightforward.   In your example their would only be a single
> > > area_type coordinate, and the value of the coordinate could simply 
> > > be "pastures .and. c4_plant_functional_types" or even "pastures and 
> > > c4_plant_functional_types"
> > > 
> > > I know this appears like a significant change to the convention, but 
> > > since area_types are just strings, I suspect that software won't care
> > > how long the strings are.   I doubt if any existing software would trip
> > > over the compound area types (except perhaps the CF checker?).
> > > 
> > > best wishes,
> > > Karl
> > > 
> > > On 1/6/17 8:59 AM, Jonathan Gregory wrote:
> > > > Dear Martin
> > > >
> > > > It's legal to have more than one axis of a given standard_name but 
> > > > it is possibly inconvenient, because analysis software could not 
> > > > use the standard_ name of those two coordinate variables to 
> > > > distinguish them; instead, it would have to use the long_name or the variable name, which is not a CF-like method.
> > > >
> > > > Another possibility would be to introduce new standard_names, 
> > > > which are more precise, such as area_type_of_land_use and 
> > > > area_type_of_vegetation in this case, while also keeping area_type 
> > > > as the union. That would require a rearrangement of the area_type table.
> > > >
> > > > On the whole, I think in this case it would be best to introduce a 
> > > > new combined area_type of pastures_of_c4_plant_functional_types i.e. flatten it.
> > > > I guess this will also be more convenient for analysts than having 
> > > > to search the combination of two dimensions. You are right of 
> > > > course that doing this could turn the area_type table into an N^2 
> > > > or even an N^n problem, which would be unmanageable, but if this 
> > > > is the
> > > > *only* use-case, or even if we had a dozen such use-cases, it is 
> > > > not a problem. Thus, I would say we cross this bridge when we come 
> > > > to it, rather than anticipating a problem which hasn't arisen yet.
> > > >
> > > > Best wishes
> > > >
> > > > Jonathan
> > > >
> > > > On Fri, Jan 06, 2017 at 11:43:57AM +0000, martin.juckes at stfc.ac.uk wrote:
> > > >> Date: Fri, 6 Jan 2017 11:43:57 +0000
> > > >> From: martin.juckes at stfc.ac.uk
> > > >> To: j.m.gregory at reading.ac.uk, taylor13 at llnl.gov, 
> > > >> alison.pamment at stfc.ac.uk
> > > >> CC: chris.d.jones at metoffice.gov.uk, cf-metadata at cgd.ucar.edu
> > > >> Subject: Composite area types in CMIP6 data
> > > >>
> > > >> Hello,
> > > >>
> > > >> In CMIP6 we have a request for some data on pasture land with C4 functional type. We already have CF area types for pasture and c4 plants in general. We could construct the required information as follows:
> > > >>
> > > >>      float pastureFracC4(time, lat, lon) ;
> > > >>          pastureFracC4:coordinates = "type ftpye" ;
> > > >>          pastureFracC4: standard_name = "area_fraction";
> > > >>          ......
> > > >>      char type(strlen) ;
> > > >>          type:long_name = "Pasture Land" ;
> > > >>          type:standard_name = "area_type" ;
> > > >>      char ftype(strlen) ;
> > > >>          ftype:long_name = "Plant Functional Type" ;
> > > >>          ftype:standard_name = "area_type" ;
> > > >> data:
> > > >>   type = "patsures" ;
> > > >>   ftype = "c4_plant_functional_types";
> > > >>
> > > >> This would provide the information that the variable pastureFracC4 refers to areas that are both "pastures" and "c4_plant_functional_types". An altenative would be to add a new area type, but I have the feeling that the area_type list will become unmanagable if we keep adding new terms for combinations of existing terms.  Can anyone see a problem with using two area_type coordinates?
> > > >>
> > > >> regards,
> > > >> Martin
> > > 
> > 



More information about the CF-metadata mailing list