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.pamm...@stfc.ac.uk> ----- > Date: Fri, 27 Apr 2018 07:14:04 +0000 > From: Alison Pamment - UKRI STFC <alison.pamm...@stfc.ac.uk> > To: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu>, "Sebastien > Villaume (sebastien.villa...@ecmwf.int)" > <sebastien.villa...@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 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.' > > 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.pamm...@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-boun...@cgd.ucar.edu] On Behalf Of > Jonathan Gregory > Sent: 16 April 2018 19:53 > To: cf-metadata@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.villa...@ecmwf.int> ----- > > > Date: Mon, 16 Apr 2018 16:05:16 +0000 (GMT-00:00) > > From: Sebastien Villaume <sebastien.villa...@ecmwf.int> > > To: Martin Juckes - UKRI STFC <martin.juc...@stfc.ac.uk> > > Cc: Karl Taylor <taylo...@llnl.gov>, cf-metadata@cgd.ucar.edu, > > Jonathan Gregory <j.m.greg...@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.juc...@stfc.ac.uk> > > > To: "Karl Taylor" <taylo...@llnl.gov>, "Sebastien Villaume" > > > <sebastien.villa...@ecmwf.int> > > > Cc: cf-metadata@cgd.ucar.edu, "Jonathan Gregory" > > > <j.m.greg...@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-boun...@cgd.ucar.edu> on behalf of > > > Sebastien Villaume <sebastien.villa...@ecmwf.int> > > > Sent: 13 April 2018 17:30 > > > To: Karl Taylor > > > Cc: cf-metadata@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" <taylo...@llnl.gov> > > >> To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>, "Lowry, Roy K." > > >> <r...@bodc.ac.uk>, "Jonathan Gregory" > > >> <j.m.greg...@reading.ac.uk> > > >> Cc: cf-metadata@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" <taylo...@llnl.gov> > > >>>> To: cf-metadata@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.villa...@ecmwf.int> > > >>>>> ----- > > >>>>> > > >>>>>> Date: Wed, 11 Apr 2018 13:57:48 +0000 > > >>>>>> From: Sebastien Villaume <sebastien.villa...@ecmwf.int> > > >>>>>> To: cf-metadata@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.villa...@ecmwf.int > > >>>>>> ____________________________________ > > >>>>>> _______________________________________________ > > >>>>>> CF-metadata mailing list > > >>>>>> CF-metadata@cgd.ucar.edu > > >>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > >>>>> ----- End forwarded message ----- > > >>>>> _______________________________________________ > > >>>>> CF-metadata mailing list > > >>>>> CF-metadata@cgd.ucar.edu > > >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > >>>> _______________________________________________ > > >>>> CF-metadata mailing list > > >>>> CF-metadata@cgd.ucar.edu > > >> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > _______________________________________________ > > > CF-metadata mailing list > > > CF-metadata@cgd.ucar.edu > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
