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,

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.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Sebastien Villaume 
Sent: 13 April 2018 17:30
To: Karl Taylor
Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
Subject: Re: [CF-metadata] use of 

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.


----- Original Message -----
From: "Karl Taylor" <taylo...@llnl.gov>
To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>, "Lowry, Roy K." 
<r...@bodc.ac.uk>, "Jonathan Gregory"
Cc: cf-metadata@cgd.ucar.edu
Sent: Friday, 13 April, 2018 16:32:39
Subject: Re: [CF-metadata] use of 
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,

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_" !


----- 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
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
, and the information in parentheses is non-standard, as provided for in

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,

On 4/11/18 10:28 AM, Jonathan Gregory wrote:
Dear Sebastien

There is an existing standard name of
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


----- 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
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 
    to the total depth. She proposed later on to simply dropped the second 
    -  Antonio Cofino argued that in this case the reference to Axis and to 
    should be removed from the description because in the case of the total 
    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

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 = 
       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
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


Dr. Sébastien Villaume

M.A.R.S. Analyst
ECMWF Data Governance facilitator

Shinfield Park,
Reading RG2 9AX, UK
+44 (0)118 949 9301
+44 (0)7825 521592
CF-metadata mailing list
----- End forwarded message -----
CF-metadata mailing list
CF-metadata mailing list
CF-metadata mailing list

CF-metadata mailing list

Reply via email to