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/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.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.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.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
Received on Mon Apr 16 2018 - 10:05:16 BST
