Dear Alison, sorry for the late reply, I have been very busy with other activities.
> 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. I am happy with this simple and straightforward approach although I would have favoured a more clear and generic way to specify these bounds. If everyone else is happy with this and if all the integral_wrt_X_of_Y standard names are updated accordingly, I will then encode my "surface to sea floor" bounds by not specifying the bounds! thanks a lot! /Sébastien ----- Original Message ----- > From: "Alison Pamment - UKRI STFC" <alison.pamm...@stfc.ac.uk> > To: cf-metadata@cgd.ucar.edu, "Sebastien Villaume > (sebastien.villa...@ecmwf.int)" <sebastien.villa...@ecmwf.int> > Sent: Friday, 27 April, 2018 08:14:04 > 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
