Dear Alison
> The question that Sebastien has raised is concerned specifically with how to state the limits on the integral_wrt_Y_of_X names and I do think we can solve the problem by modifying the definitions along the lines Jonathan suggests. Currently the definitions all say 'The phrase "integral_wrt_X_of_Y" means int Y dX. The data variable should have an axis for X specifying the limits of the integral as bounds.' We could modify this to read 'The phrase "integral_wrt_X_of_Y" means int Y dX. To specify the limits of the integral the data variable should have an axis for X and associated coordinate bounds. If no axis for X is associated with the data variable, or no coordinate bounds are specified, it is assumed that the integral is calculated over the entire vertical extent of the medium, e.g, if the medium is air the integral is assumed to be calculated over the full depth of the atmosphere.'
Yes, I think that's a good approach. Are there really as many of these names as
you say? It's only the vertical integrals we're discussing, not the integrals
wrt time.
I agree with you in not wanting to rename the "content" quantities as
vertical integrals. I advocate only merging the names of type Z_CONTENT with
CONTENT_in_Z_layer, where the distinction is solely that the former is an
integral over the entire vertical extent of Z.
Best wishes
Jonathan
----- Forwarded message from Alison Pamment - UKRI STFC <alison.pamment at stfc.ac.uk> -----
> Date: Fri, 27 Apr 2018 07:14:04 +0000
> From: Alison Pamment - UKRI STFC <alison.pamment at stfc.ac.uk>
> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>, "Sebastien
> Villaume (sebastien.villaume at ecmwf.int)"
> <sebastien.villaume at ecmwf.int>
> Subject: Re: [CF-metadata] use of
> integral_wrt_depth_of_sea_water_practical_salinity
>
> Dear Sebastien, All,
>
> I have just been reading through this thread and it raises some interesting points.
>
> When I made my original comments back in 2016 (that ocean_integral_wrt_depth_of_sea_water_practical_salinity (i.e. integral over the whole depth from sea floor to surface) is a special case of integral_wrt_depth_of_sea_water_practical_salinity) I don't think I had fully thought through how one would go about specifying the limits for the full depth case. I see now that we don't really have an agreed mechanism for doing this, although a number of ideas have been put forward. I agree with Martin's comment that one would expect to look at the coordinates and coordinate bounds for the limits of an integral - certainly that's what we do for cases where the limits define a layer and I think it's preferable to treat the full depth case similarly.
>
> Jonathan suggested making the existing in_atmosphere_layer/in_ocean_layer names aliases of the full depth atmosphere/ocean names and stating in the definition that if coordinate bounds are not specified it means the entire vertical extent of the atmosphere/ocean. The question that Sebastien has raised is concerned specifically with how to state the limits on the integral_wrt_Y_of_X names and I do think we can solve the problem by modifying the definitions along the lines Jonathan suggests. Currently the definitions all say 'The phrase "integral_wrt_X_of_Y" means int Y dX. The data variable should have an axis for X specifying the limits of the integral as bounds.' We could modify this to read 'The phrase "integral_wrt_X_of_Y" means int Y dX. To specify the limits of the integral the data variable should have an axis for X and associated coordinate bounds. If no axis for X is associated with the data variable, or no coordinate bounds are specified, it is assumed that the integral is calculated over the enti
re vertical extent of the medium, e.g, if the medium is air the integral is assumed to be calculated over the full depth of the atmosphere.'
>
> If we take this approach then Sebastien could use the existing integral_wrt_depth_of_sea_water_practical_salinity name and it would cover all use cases. Do others agree? If so, then I will modify the definitions of all 387 existing integral names in the next update. This will create some housekeeping work for the standard name table, but it avoids the need to modify the conventions which would be necessary for some of the other ideas that have been discussed in this thread.
>
> As to whether we should make layer names into aliases, e.g. mass_content_of_cloud_ice_in_atmosphere_layer becoming an alias of atmosphere_mass_content_of_cloud_ice, we could certainly do this by taking a similar approach regarding bounds in the definitions, but strictly speaking, it's not necessary to do this to address Sebastien's question. Also, if we are trying to be completely consistent about integrals and layers, it raises the question of whether atmosphere_mass_content, atmosphere_mole_content, etc, names should all be changed to integral names. For example, should both the existing mass_content_of_cloud_ice names be turned into aliases of a new name integral_wrt_height_of_mass_of_cloud_ice_in_air? Personally, I don't feel it would make the names any clearer so I'm not keen on following that idea. I think it's preferable to stick with fixing the integral definitions to cope with all bounds possibilities.
>
> Best wishes,
> Alison
>
> ------
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data Archival Email: alison.pamment at stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: 16 April 2018 19:53
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] use of integral_wrt_depth_of_sea_water_practical_salinity
>
> Dear Sebastien et al.
>
> It's allowed to put "depth: mean" in cell_methods even if there is no depth coordinate variable (and no bounds). This is described in sect 7.3.4 of the convention. It's allowed by the "first" case described there, because depth is a standard name. We could suit your case better if we explicitly allowed the "second" case of 7.3.4 to apply to the vertical coordinate, meaning the range over the complete vertical extent where the quantity is defined i.e.
> from the sea surface to the sea floor for an ocean quantity. Would this be a good solution?
>
> Since some more general issues have been raised, I'd like to comment on them.
>
> First, there are a number of pairs of standard names, where one of the pair is for the whole vertical extent of the atmosphere or the ocean, and the other is for a layer within it e.g.
> atmosphere_mass_content_of_cloud_ice
> mass_content_of_cloud_ice_in_atmosphere_layer
> This is my fault or choice, I believe, but from a *long* time ago - almost 20 years ago. I've often thought that maybe this was a mistake, because it is the sort of distinction which could be made by bounds, and perhaps this present discussion indicates that we should change it. One possibility would to make the in_atmosphere/ocean_layer aliases of the atmosphere/ocean_ names, and say in the definition that if coordinate bounds are not specified it means the entire vertical extent of the atmosphere/ocean. That is, the distinction would rely on the presence of bounds. Would this be good?
>
> Second, Sebastien comments that, "Many standard names make reference to time, space, post-processing." Actually I do not think that is true. As you say, the description of the processing belongs in the cell_methods. That is why we don't have standard_names for daily maximum and daily mean air temperature, for example, although they are common concepts. However, it does depend what you regard as "post-processing". The integral_wrt_X_of_Y is regarded by the standard name guidelines as a "transformation", which derives one quantity from one or more other quantities, and not as post-processing. In this case in CF terms it is clear that the new quantity is different from the old one, because the units of the new one are the product of the units of X and Y, whereas the units of a quantity which has been post-processed by cell_methods can depend only on the units it originally had.
>
> Third, there have been many discussions about whether to allow lots more names of a certain kind (as we did in the case of the isotopes recently, and as for chemical species) or whether instead to factorise a new distinction into a coordinate variable (as Roy is proposing for the biological taxa, and as for area types and region names). We always consider this choice carefully! I think there are good arguments for having most of the non-numeric metadata in the standard name - see www.met.reading.ac.uk/~jonathan/CF_metadata/14.1/#direction
> for my reasons.
>
> Best wishes
>
> Jonathan
>
> ----- Forwarded message from Sebastien Villaume <sebastien.villaume at ecmwf.int> -----
>
> > Date: Mon, 16 Apr 2018 16:05:16 +0000 (GMT-00:00)
> > From: Sebastien Villaume <sebastien.villaume at ecmwf.int>
> > To: Martin Juckes - UKRI STFC <martin.juckes at stfc.ac.uk>
> > Cc: Karl Taylor <taylor13 at llnl.gov>, cf-metadata at cgd.ucar.edu,
> > Jonathan Gregory <j.m.gregory at reading.ac.uk>
> > Subject: Re: use of integral_wrt_depth_of_sea_water_practical_salinity
> > X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF57
> > (Linux)/8.6.0_GA_1200)
> >
> > Hi Martin,
> >
> > This is interesting because it makes me realize that I am not the only one facing these issues with "special" bounds that are function of other variables...
> >
> > I like the idea of "pseudo-controlled" cell_method construction but in my case I would require something like:
> >
> > cell_method = "depth: integral from X to Y (where Z)"
> >
> > with X being "surface" and Y being "sea_floor" with eventually a "where" clause with Z being "sea".
> >
> >
> > I think that this kind of issues should not be solved on a case-by-case basis but addressed in a general context because the case-by-case approach always leads to specific solutions...
> >
> >
> > /S?bastien
> >
> > ----- Original Message -----
> > > From: "Martin Juckes - UKRI STFC" <martin.juckes at stfc.ac.uk>
> > > To: "Karl Taylor" <taylor13 at llnl.gov>, "Sebastien Villaume"
> > > <sebastien.villaume at ecmwf.int>
> > > Cc: cf-metadata at cgd.ucar.edu, "Jonathan Gregory"
> > > <j.m.gregory at reading.ac.uk>
> > > Sent: Monday, 16 April, 2018 10:02:28
> > > Subject: Re: use of
> > > integral_wrt_depth_of_sea_water_practical_salinity
> >
> > > Hello Karl, Sebastien,
> > >
> > >
> > > I'm not sure that I've understood the whole thread, but to me it
> > > looks as though the coordinate bounds would be the natural place to
> > > deal with this, though it would require a modification to the convention.
> > >
> > >
> > > There was a related, inconclusive, discussion in 2016 on the
> > > encoding of histogram bin ranges in the case where some bins are not
> > > defined by the numerical ranges that the current convention permits
> > > for coordinate bounds
> > > (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/059037.html
> > > ). The idea of using flag_values and flag_meanings came up. For the
> > > current example you could set the lower value of the depth
> > > coordinate bounds of the vertical integral to -50000 [m] and then have flag_values=-50000, flag_meanings="ocean_floor".
> > >
> > >
> > > Alternatively, there appears to be agreement in
> > > https://cf-trac.llnl.gov/trac/ticket/152 that the cell_methods
> > > construction "mean where X" does not need to me restricted to
> > > horizontal spatial means. That ticket discusses using it for
> > > temporal means, but it could also be used for depth means, as in:
> > >
> > > "cell_methods = mean: depth where sea". The idea that the CF area type "sea"
> > > can be depth dependant was accepted in a discussion of usage in
> > > CMIP6, where we have many variables which require the surface sea
> > > extent, and others which require the total sea extent, including the
> > > small but significant portion extending under floating ice shelves.
> > > This would make the flag_values/meanings construction redundant.
> > >
> > >
> > > Incidentally, the cell_methods string can be parsed by David
> > > Hassell's cf python library (https://pypi.python.org/pypi/cf-python
> > > ). This doesn't entirely solve the problem because of the variable
> > > quality of the information that has been encoded in the cell_methods
> > > string in the past ... but it does give us a tool to use in our efforts to improve the situation.
> > >
> > >
> > > regards,
> > >
> > > Martin
> > >
> > >
> > >
> > > ________________________________
> > > From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of
> > > Sebastien Villaume <sebastien.villaume at ecmwf.int>
> > > Sent: 13 April 2018 17:30
> > > To: Karl Taylor
> > > Cc: cf-metadata at cgd.ucar.edu; Jonathan Gregory
> > > Subject: Re: [CF-metadata] use of
> > > integral_wrt_depth_of_sea_water_practical_salinity
> > >
> > > Hi Karl,
> > >
> > > I tend to agree that this solution is far from ideal.
> > >
> > > The core issue is that there is no clear separation between a
> > > parameter (diagnostic quantities, observables, coordinates etc.) and
> > > what you do with it in CF: everything is squeezed in the standard
> > > name and in the cell_method (in a non-consistent way).
> > >
> > > In an ideal world, the standard names should only describe bare
> > > parameters and everything related to processing should go into
> > > something else. But many standard names make reference to time,
> > > space, post-processing, extra useful informations, etc.
> > > The cell_method attribute is in principle there to represent any
> > > (post-)processing but it is not always the case, sometimes the
> > > informations are in the standard name directly or sometimes the
> > > cell_method is too limited to describe what needs to be described. like in my case here...
> > > To maintain a strict separation, the "integral_wrt_X_of_Y" should be
> > > one of the cell_method from the beginning.... I also never
> > > understood why "difference" is not a valid method in the table E.1 of appendix E since "sum" is there.
> > >
> > > I noticed few months ago a thread discussing ontologies in
> > > connection with the proposal of standard names for isotopes.
> > > Hundreds of new standard names were added. To me this was all wrong:
> > > only few standard names should have been
> > > added: mass_concentration, density, optical_depth, whatever physical
> > > property you like. Each variable holding one of these standard name
> > > should point to a scalar through a controlled attribute. The scalar
> > > should name the isotope or the type of particle or the chemical constituent, etc.
> > > I can already see coming hundreds of new standard names each time a
> > > new useful property for isotopes or molecules is required.
> > >
> > > You will not prevent explosion of standard names if you don't limit
> > > them to the "what". The "when" should go in the time variable(s),
> > > the "where" in the spatial variables, and finally the "how" either
> > > in the cell_method with clear controlled vocabulary or using a new controlled mechanism yet to define.
> > >
> > > /S?bastien
> > >
> > > ----- Original Message -----
> > >> From: "Karl Taylor" <taylor13 at llnl.gov>
> > >> To: "Sebastien Villaume" <sebastien.villaume at ecmwf.int>, "Lowry, Roy K."
> > >> <rkl at bodc.ac.uk>, "Jonathan Gregory"
> > >> <j.m.gregory at reading.ac.uk>
> > >> Cc: cf-metadata at cgd.ucar.edu
> > >> Sent: Friday, 13 April, 2018 16:32:39
> > >> Subject: Re: [CF-metadata] use of
> > >> integral_wrt_depth_of_sea_water_practical_salinity
> > >
> > >> Dear all,
> > >>
> > >> I am wary of a "slippery slope" if every calculation performed on a
> > >> quantity results in a new standard name for that quantity. We have
> > >> tried to avoid that in most cases by use of the cell methods,
> > >> bounds, and climatology attributes. Isn't there some way to
> > >> accommodate this in a more general way? I agree that use of
> > >> non-controlled vocabulary is not ideal, but I would be interested
> > >> in the kind of use case you envision where you would have to parse
> > >> it? How does definition of a new standard name satisfy your use case of machine interpretation?
> > >>
> > >> best regards,
> > >> Karl
> > >>
> > >>
> > >> On 4/13/18 8:22 AM, Sebastien Villaume wrote:
> > >>> Dear Jonathan, Roy and Karl,
> > >>>
> > >>> thank you for your valuable inputs.
> > >>>
> > >>> I am not very fond of the cell_method solution: I am already very
> > >>> reluctant using it because it is not controlled vocabulary and it
> > >>> is a nightmare to parse to extract valuable metadata
> > >>> automatically. Now that I am discovering that one can use a
> > >>> standard_name with no attached bounds instead of a proper variable name with associated bounds makes me even more reluctant to use it!
> > >>>
> > >>> But I am not in a favour of encoding huge values of depth either...
> > >>>
> > >>> ... which leaves me being in favour of proposing new standard
> > >>> names by prefixing existing standard names with "ocean_" !
> > >>>
> > >>>
> > >>> /S?bastien
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Karl Taylor" <taylor13 at llnl.gov>
> > >>>> To: cf-metadata at cgd.ucar.edu
> > >>>> Sent: Wednesday, 11 April, 2018 18:45:07
> > >>>> Subject: Re: [CF-metadata] use of
> > >>>> integral_wrt_depth_of_sea_water_practical_salinity
> > >>>> Dear Sebastien,
> > >>>>
> > >>>> One option would be to include in cell_methods the following:
> > >>>>
> > >>>> cell_methods = "depth: mean (from surface to sea floor)"
> > >>>>
> > >>>> where depth is the standard name for the vertical coordinate, as
> > >>>> provided for in
> > >>>> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/c
> > >>>> f-conventions.html#cell-methods-no-coordinates
> > >>>> , and the information in parentheses is non-standard, as provided
> > >>>> for in
> > >>>> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/c
> > >>>> f-conventions.html#recording-spacing-original-data
> > >>>> .
> > >>>>
> > >>>> I, for one, wouldn't like to see every integral over an entire
> > >>>> domain to require a new standard_name. the standard_names should
> > >>>> name the variable itself and not indicate "method".
> > >>>>
> > >>>> best wishes,
> > >>>> Karl
> > >>>>
> > >>>>
> > >>>> On 4/11/18 10:28 AM, Jonathan Gregory wrote:
> > >>>>> Dear Sebastien
> > >>>>>
> > >>>>> There is an existing standard name of
> > >>>>> ocean_integral_wrt_depth_of_sea_water_temperature
> > >>>>> and the one you propose has the same pattern, so it would seem
> > >>>>> all right to me, and appropriate for your purpose. Otherwise you
> > >>>>> could set a very large lower depth boundary with the
> > >>>>> understanding that integrating below the sea floor added nothing, but that's a bit ugly.
> > >>>>>
> > >>>>> Best wishes
> > >>>>>
> > >>>>> Jonathan
> > >>>>>
> > >>>>> ----- Forwarded message from Sebastien Villaume
> > >>>>> <sebastien.villaume at ecmwf.int>
> > >>>>> -----
> > >>>>>
> > >>>>>> Date: Wed, 11 Apr 2018 13:57:48 +0000
> > >>>>>> From: Sebastien Villaume <sebastien.villaume at ecmwf.int>
> > >>>>>> To: cf-metadata at cgd.ucar.edu
> > >>>>>> Subject: [CF-metadata] use of
> > >>>>>> integral_wrt_depth_of_sea_water_practical_salinity
> > >>>>>> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF57
> > >>>>>> (Linux)/8.6.0_GA_1200)
> > >>>>>>
> > >>>>>> Dear list,
> > >>>>>>
> > >>>>>> In 2016/2017, a list of new standard names for NEMO output has
> > >>>>>> been proposed and accepted :
> > >>>>>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/058964.h
> > >>>>>> tml
> > >>>>>>
> > >>>>>> from that initial list of standard names and after many
> > >>>>>> iterations, one of the accepted standard name was:
> > >>>>>>
> > >>>>>> standard name:
> > >>>>>> integral_wrt_depth_of_sea_water_practical_salinity
> > >>>>>> units: m
> > >>>>>>
> > >>>>>> But the initial list of proposed standard names had actually 2
> > >>>>>> entries for this standard name:
> > >>>>>>
> > >>>>>> - one entry which is the one that eventually made it to the
> > >>>>>> list (the standard name above)
> > >>>>>> - a second entry for the case where the depth is the total
> > >>>>>> depth, from surface to sea floor:
> > >>>>>> ocean_integral_wrt_depth_of_sea_water_practical_salinity
> > >>>>>>
> > >>>>>> During the discussion:
> > >>>>>> - Alison argued that the 2 entries were actually identical, the second one
> > >>>>>> being simply a special case of the first one, i.e. when the depth corresponds
> > >>>>>> to the total depth. She proposed later on to simply dropped the second entry.
> > >>>>>> - Antonio Cofino argued that in this case the reference to Axis and to bounds
> > >>>>>> should be removed from the description because in the case of the total depth,
> > >>>>>> the bounds are not a constant (but function of lat and lon)
> > >>>>>>
> > >>>>>> In the published description the reference to an axis and to
> > >>>>>> bounds is still there.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> My immediate problem is that I want to produce a parameter that
> > >>>>>> is the integral wrt the whole depth of the salinity and I don't know how to do this.
> > >>>>>>
> > >>>>>> for a fixed depth of 500m for instance, the metadata for the parameter would be:
> > >>>>>>
> > >>>>>> float salinity500(t, y, x) ;
> > >>>>>> salinity500:standard_name = "integral_wrt_depth_of_sea_water_practical_salinity"
> > >>>>>> ;
> > >>>>>> salinity500:units = "m" ;
> > >>>>>> salinity500:coordinates = "time dpt500 latitude
> > >>>>>> longitude" ; float dpt500 ;
> > >>>>>> dpt500:standard_name = "depth_below_geoid" ;
> > >>>>>> dpt500:units = "m" ;
> > >>>>>> dpt500:axis = "Z" ;
> > >>>>>> dpt500:positive = "down" ;
> > >>>>>> dpt500:bounds = dpt500_bnds ; float dpt500_bnds(bnds) ;
> > >>>>>>
> > >>>>>> and in the dpt500_bnds array, I have : [0., 500.]
> > >>>>>>
> > >>>>>> for the total depth, I can't use the same mechanism, because
> > >>>>>> the second value of the bounds is not a constant, it is a
> > >>>>>> function of lat and lon: [0., f(lat,lon)]
> > >>>>>>
> > >>>>>>
> > >>>>>> How can I solve this?
> > >>>>>>
> > >>>>>> Is it possible to reconsider the standard name
> > >>>>>> ocean_integral_wrt_depth_of_sea_water_practical_salinity (or a
> > >>>>>> variation of it)?
> > >>>>>> Another approach could be to keep the existing standard name,
> > >>>>>> add a new standard name that represents the total water column
> > >>>>>> and use it as an auxiliary coordinate.
> > >>>>>>
> > >>>>>> thanks,
> > >>>>>> ____________________________________
> > >>>>>>
> > >>>>>> Dr. S?bastien Villaume
> > >>>>>>
> > >>>>>> M.A.R.S. Analyst
> > >>>>>> ECMWF Data Governance facilitator
> > >>>>>>
> > >>>>>> ECMWF
> > >>>>>> Shinfield Park,
> > >>>>>> Reading RG2 9AX, UK
> > >>>>>> +44 (0)118 949 9301
> > >>>>>> +44 (0)7825 521592
> > >>>>>> sebastien.villaume at ecmwf.int
> > >>>>>> ____________________________________
> > >>>>>> _______________________________________________
> > >>>>>> CF-metadata mailing list
> > >>>>>> CF-metadata at cgd.ucar.edu
> > >>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > >>>>> ----- End forwarded message -----
> > >>>>> _______________________________________________
> > >>>>> CF-metadata mailing list
> > >>>>> CF-metadata at cgd.ucar.edu
> > >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > >>>> _______________________________________________
> > >>>> CF-metadata mailing list
> > >>>> CF-metadata at cgd.ucar.edu
> > >> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > _______________________________________________
> > > CF-metadata mailing list
> > > CF-metadata at cgd.ucar.edu
> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Wed May 02 2018 - 10:20:36 BST
