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.pamment at stfc.ac.uk>
> To: cf-metadata at cgd.ucar.edu, "Sebastien Villaume (sebastien.villaume at ecmwf.int)" <sebastien.villaume at 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.pamment at 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-bounces at cgd.ucar.edu] On Behalf Of
> Jonathan Gregory
> Sent: 16 April 2018 19:53
> To: cf-metadata at 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.villaume at ecmwf.int>
> -----
>
>> Date: Mon, 16 Apr 2018 16:05:16 +0000 (GMT-00:00)
>> From: Sebastien Villaume <sebastien.villaume at ecmwf.int>
>> To: Martin Juckes - UKRI STFC <martin.juckes at stfc.ac.uk>
>> Cc: Karl Taylor <taylor13 at llnl.gov>, cf-metadata at cgd.ucar.edu,
>> Jonathan Gregory <j.m.gregory at 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.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/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.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.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.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
>
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri May 18 2018 - 07:02:05 BST
