Hi Karl,
yes, thanks for correcting that, Martin ________________________________ From: Karl Taylor <taylo...@llnl.gov> Sent: 16 April 2018 16:43 To: Juckes, Martin (STFC,RAL,RALSP); Sebastien Villaume Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory Subject: Re: use of integral_wrt_depth_of_sea_water_practical_salinity Hi Martin, To be sure, did you reverse the words in your example of cell_methods? Should it read: "cell_methods = depth: mean where sea" ? best regards, Karl On 4/16/18 2:02 AM, Martin Juckes - UKRI STFC wrote: > 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/cf-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/cf-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.html >>>>>> >>>>>> 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 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
