Re: [CF-metadata] CMIP6: just one name remaining!

[Martin Juckes - UKRI STFC]

Dear Jean-Yves, Didier,


please could you take a look at the following question about the CMIP6 variable 
"sw2h" which has title "Isotopic Ratio of Deuterium in Sea Water" and 
description "Ratio of abundance of hydrogen-2 (2H) atoms to hydrogen-1 (1H) 
atoms in sea water", and proposed standard name: 
"isotope_ratio_of_2H_to_1H_in_sea_water_excluding_solutes_and_solids".


As it stands, the working definition implies that this should be:  ( [DH0] + 
2[D2O] )/ [H2O] ), where "[]" indicates the abundance of the molecule and "D" 
is deuterium. I.e. the ratio of the number density of deuterium atoms contained 
in water molecules to the number density of hydrogen atoms in water molecules. 
Is this the quantity which is needed for you analysis?


regards,

Martin



________
From: CF-metadata  on behalf of Martin Juckes 
- UKRI STFC 
Sent: 05 July 2018 10:39
To: Pamment, Alison (STFC,RAL,RALSP); CF-metadata (cf-metadata@cgd.ucar.edu); 
Didier M. Roche; Jean-Yves Peterschmitt
Subject: Re: [CF-metadata] CMIP6: just one name remaining!

Dear Didier, Jean-Yves,


we need to clear up one remaining ambiguity in the definition of the variable 
sw2H, which is related to deuterium in sea water.


In the table that Jean-Yves posted on github 
(https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/316) 
it is described with a long name "1H2HO in sea water" and description "Ratio of 
2H in sea water".


Is the quantity you want the ratio of 1H.2H.O the number of molecules to the 
total 1H2.O molecules?


For the sw18O and sw17O variables we used standard names which refer to the 
ration of 18O atoms to 16O atoms (e.g. 
isotope_ratio_of_18O_to_16O_in_sea_water_excluding_solutes_and_solids  -- the 
last part is needed because "sea_water" in standard names is interpreted as 
including not only the H2O but also the solutes and suspended solids that go 
with it). That approach won't work here if we are dealing with only the 
deuterium in water molecules which contain a single deuterium atom.


The term "isotope" is usually, as far as I can tell, interpreted as referring 
to atoms, but can be used to refer to molecules. I suggest we mention the fact 
that we are referring to a ratio of molecular isotopes in the standard name (if 
my interpretation above is correct). We have some agreed terms such as 
precipitation_flux_containing_single_2H (for pr2H) which are related to 1H.2H.O 
molecules. We decided not to try to use a name for the molecule, as different 
people have different names for these isotopes, and instead we have tried to 
spell out the detail in the standard name.


Following that approach here, we might use:

water_molecule_isotope_ratio_of_single_2H_to_double_1H_in_sea_water_excluding_solutes_and_solids


Does that make sense? I'm I correct in thinking that you want the ration of 
2H.1H.O to 1H2.O for this variable?


regards,

Martin



From: Pamment, Alison (STFC,RAL,RALSP)
Sent: 04 July 2018 16:19
To: CF-metadata (cf-metadata@cgd.ucar.edu); Juckes, Martin (STFC,RAL,RALSP)
Subject: CMIP6: just one name remaining!


Dear Martin,



After all the progress in recent weeks we have now reached the position where 
there is just one CMIP6 name remaining to be agreed.



It is the PMIP name:

isotope_ratio_of_2H_to_1H_in_sea_water_excluding_solutes_and_solids (1)

‘The phrase "ratio_of_X_to_Y" means X/Y. The phrase "isotope_ratio" is used in 
the construction isotope_ratio_of_A_to_B where A and B are both named isotopes. 
It means the ratio of the number of atoms of A to the number of atoms of B 
present within a medium. "H" means the element "hydrogen" and "2H" is the 
stable isotope "hydrogen-2", usually called "deuterium". "1H" is the stable 
isotope "hydrogen-1". The phrase "in_sea_water_excluding_solutes_and_solids" 
means that the standard name refers to the composition of the sea water medium 
itself and does not include material that may be dissolved or suspended in the 
medium.’



The question that we need to resolve is whether '2H' includes water composed of 
both HDO and D2O. The name as it stands could be understood to mean the ratio 
of all 2H to 1H in sea water, regardless of whether the 2H occurs in heavy or 
semiheavy water, but this may not be the intention.



To publish the last few CMIP names I am planning a ‘mini update’ to the 
standard name table next week. It would be great if we could sort out this 
remaining one in time to include it!



Best wishes,

Alison



--

Alison Pamment Tel: +44 1235 778065

NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk

STFC Rutherford Appleton Laboratory

R25, 2.22

Harwell Oxford, Didcot, OX11 0QX, U.K.


__

[CF-metadata] Defining bedrock in CF Standard Names

[Martin Juckes - UKRI STFC]

Dear Magnus,


I'm writing to you because I'd like to clear up some slight ambiguities in the 
usage of the term `bedrock` in CF Standard Names, and you led a discussion to 
introduce some of these terms back in 2004.


There are more details on https://github.com/cf-convention/discuss/issues/2


If you are still interested in these issues, please take a look and add your 
comments,


sincerely,

Martin Juckes
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] order of product in standard name

[Martin Juckes - UKRI STFC]

Dear Alison,


apologies for not responding earlier -- it looks as though both I and Jonathan 
missed you proposed resolution of the discussion about:

covariance_over_longitude_of_northward_wind_and_air_temperature (Canonical 
units: K m s-1)


I agree with this formulation of the term and your proposed text. Thanks for 
putting this together,


regards,

Martin


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 03 June 2019 16:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] order of product in standard name

Dear Jonathan and Martin,

Thank you both for your comments.

I think the product names are now agreed. I withheld them from the May update 
due to the continuation of the discussion but will now mark them as accepted 
and add them in the June update:
*   product_of_eastward_wind_and_lagrangian_tendency_of_air_pressure
*   product_of_northward_wind_and_lagrangian_tendency_of_air_pressure
*   product_of_lagrangian_tendency_of_air_pressure_and_specific_humidity
*   product_of_lagrangian_tendency_of_air_pressure_and_air_temperature
*   product_of_lagrangian_tendency_of_air_pressure_and_geopotential_height.

I think we are now agreed on 
covariance_over_longitude_of_northward_wind_and_air_temperature (Canonical 
units: K m s-1). I agree with Martin's suggestion to include 'Covariance refers 
to the sample covariance rather than the population covariance' in the 
definition. Putting this together with other comments in the discussion, plus 
our usual text for some of the terms, I suggest the following:
'Covariance refers to the sample covariance rather than the population 
covariance. The quantity with standard name 
covariance_over_longitude_of_northward_wind_and_air_temperature is the 
covariance of the deviations of meridional air velocity and air temperature 
about their respective zonal mean values. The data variable must be accompanied 
by a vertical coordinate variable or scalar coordinate variable and is 
calculated on an isosurface of that vertical coordinate. "Northward" indicates 
a vector component which is positive when directed northward (negative 
southward). Wind is defined as a two-dimensional (horizontal) air velocity 
vector, with no vertical component. (Vertical motion in the atmosphere has the 
standard name "upward_air_velocity"). Air temperature is the bulk temperature 
of the air, not the surface (skin) temperature.'

Is that okay?

Best wishes,
Alison

---
Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Jonathan 
Gregory
Sent: 30 May 2019 22:49
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] order of product in standard name

Dear Alison

I agree with all this and support Martin's suggestions that you have enacted.
I agree that omega is like w and it's normal to write wT.

Best wishes and thanks

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Thu, 30 May 2019 13:12:10 +
> From: Alison Pamment - UKRI STFC 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] order of product in standard name
>
> Dear Jonathan and Martin,
>
> I would like to make sure that we have fully resolved this issue as it 
> affects names that are currently under discussion in two threads:
> covariance_over_longitude_of_northward_wind_and_air_temperature (latest 
> comment: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020922.html);
> also:
>   *   product_of_eastward_wind_and_lagrangian_tendency_of_air_pressure
>   *   product_of_northward_wind_and_lagrangian_tendency_of_air_pressure
>   *   product_of_lagrangian_tendency_of_air_pressure_and_specific_humidity
>   *   product_of_lagrangian_tendency_of_air_pressure_and_air_temperature
>   *   product_of_lagrangian_tendency_of_air_pressure_and_geopotential_height
> (latest comment 
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020927.html).
>
> I agree with Jonathan that for covariance and correlation names it is better 
> to have covariance_over_Z_of_X_and_Y, (rather than putting over_Z at the end 
> as stated in the current guidelines). This is consistent with the way we now 
> write integrals as integral_wrt_X_of_Y.
>
> The current guidelines for correlation and covariance say simply that X and Y 
> should be ordered alphabetically, whereas for product we have additional 
> guidance: 'If X and Y are both scalars or both components of vectors, they 
> are put in alphabetical order. If one of them is the component of a vector, 
> it is put first i.e. the vector component is X, the scalar is Y.'
>
> I think we are agreed that the same guidelines should 

Re: [CF-metadata] New standard_name of quality_flag for corresponding quality control variables

[Martin Juckes - UKRI STFC]

Dear Ken,


Can you expand on the distinction between "quality" and "status"? I understand 
that they are different in principle, but, in order to support this new 
standard name I think we need a clear objective statement of how we would want 
to distinguish between them in CF.

The conventions section on flags (3.5) mixes the two up 
(http://cfconventions.org/cf-conventions/cf-conventions.html#flags ), so some 
re-wording of the document would also be needed,

regards,
Martin


From: CF-metadata  on behalf of Kehoe, 
Kenneth E. 
Sent: 19 July 2019 06:42
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New standard_name of quality_flag for corresponding 
quality control variables

Dear CF,

I am proposing a new standard name of "quality_flag" to indicate a variable is 
purely a quality control variable. A quality control variable would use 
flag_values or flag_masks along with flag_meanings to allow declaring levels of 
quality or results from quality indicating tests of the data variable. This 
variable be a subset of the more general "status_flag" standard name. Currently 
the definition of "status_flag" is:

- A variable with the standard name of status_flag contains an indication of 
quality or other status of another data variable. The linkage between the data 
variable and the variable with the standard_name of status_flag is achieved 
using the ancillary_variables attribute.

This definition includes a variable used to define the state or other status 
information of a variable and can not be distinguished by standard name alone 
from a state of the instrument, processing decision, source information, needed 
metadata about the data variable or other ancillary variable type. Since there 
is no other way to define a purely quality control variable, the use of 
"status_flag" is too general for strictly quality control variables. By having 
a method to define a variable as strictly quality control the results of 
quality control tests can be applied to the data with a software tool based on 
requests by the user. This would not affect current datasets that do use 
"status_flag" nor require a change to the definition outside of the indication 
that "quality_flag" standard name is available and a better use for pure 
quality control variables.

Proposed addition:

quality_flag = A variable with the standard name of quality_flag contains an 
indication of quality information of another data variable. The linkage between 
the data variable and the variable or variables with the standard_name of 
quality_flag is achieved using the ancillary_variables attribute.

Proposed change:

status_flag = A variable with the standard name of status_flag contains an 
indication of status of another data variable. The linkage between the data 
variable and the variable with the standard_name of status_flag is achieved 
using the ancillary_variables attribute. For data quality information use 
quality_flag.

Thanks,

Ken



--
Kenneth E. Kehoe
  Research Associate - University of Oklahoma
  Cooperative Institute for Mesoscale Meteorological Studies
  ARM Climate Research Facility - Data Quality Office
  e-mail: kke...@ou.edu | Office: 303-497-4754
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Indices or Labels as Coordinate Variables

[Martin Juckes - UKRI STFC]

OK, I've raise an issue here: 
https://github.com/cf-convention/cf-conventions/issues/174


cheers,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 12 July 2019 13:53:45
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Indices or Labels as Coordinate Variables

Dear Martin

Ah, I see. I agree that this is a defect now in our text if they have changed
what they say. I also agree that we should stick with what we've got i.e. more
restrictive, coord vars are 1D, numeric, and monotonic and called the same as
their dimension. That's our data model.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Fri, 12 Jul 2019 08:43:33 +
> From: Martin Juckes - UKRI STFC 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] Indices or Labels as Coordinate Variables
>
> Hello Tom, Jonathan,
>
>
> that is interesting. It looks like a change introduced in NetCDF 4 which CF 
> has not caught up with. Do you think they really mean what they say about the 
> values having to be strictly monotonic?
>
>
> The convention does say we use this term "term precisely as it is defined in 
> the NUG section on coordinate variables", but we also state that it must be 
> numeric. Perhaps we should take "precisely" out of that sentence (I think it 
> was true in NetCDF 3)? Keeping string values out of the array dimensions and 
> preserving a clear rule about monotonicity looks like the best approach to me,
>
>
> regards,
>
> Martin
>
>
>
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 10 July 2019 17:55
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Indices or Labels as Coordinate Variables
>
> Dear Tom
>
> That's interesting. I did not know or had forgotten about that Unidata
> recommendation. CF doesn't allow string-valued coordinate variables (with
> the same name as any of their dimensions), only string-valued auxiliary
> coordinate variables.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Tom Evans  -
>
> > Date: Tue, 9 Jul 2019 23:08:46 +
> > From: Tom Evans 
> > To: Jonathan Gregory 
> > Subject: RE: [CF-metadata] Indices or Labels as Coordinate Variables
> >
> > Dear Jonathan
> >
> > Thanks very much for your response. It really did help me understand the 
> > use of coordinate values. In particular, your suggestion that an auxiliary 
> > coordinate variable (with a different name from the dimension) could be 
> > listed in the coordinate attribute of a variable is very helpful. It 
> > produces exactly the behaviour I'd look for in Panoply, for example.
> >
> > I have a follow-up question, if you don't mind:
> >
> > The Best Practices page at the Unidata site also mentions a "string-valued 
> > coordinate variable," which has the same name as its first dimension, e.g.
> >
> >char location(location, loc_len)
> >
> > where loc_len is the length of a text label for the location. The CF 
> > specification mentions a "string-valued auxiliary coordinate variable" -- 
> > something like
> >
> >char location_name(location, loc_len)
> >
> > if I'm following this correctly -- which could also be used as a coordinate 
> > in the attribute -- but it doesn't say anything about a string-valued 
> > variable with the same name as a dimension. I also haven't found any 
> > examples that use string-valued coordinate variables named the same as a 
> > dimension. Would such a variable risk conflict or confusion with the 
> > assumptions of applicactions designed to work with CF-compliant data?
> >
> > Cheers
> > Tom Evans
> >
> >
> >
> >
> >
> > [cid:image702fcb.PNG@5e3232e3.49822ae5]<http://www.niwa.co.nz>
> >
> >
> > Dr Tom Evans
> > Software Developer
> > T +64-7-859-1832
> >
> > National Institute of Water & Atmospheric Research Ltd (NIWA)
> > Gate 10 Silverdale Road, Hillcrest, Hamilton
> > Connect with NIWA: niwa.co.nz<https://www.niwa.co.nz> 
> > Facebook<https://www.facebook.com/nzniwa> 
> > Twitter<https://twitter.com/niwa_nz> 
> > LinkedIn<https://www.linkedin.com/company/niwa> 
> > Instagram<https://www.instagram.com/niwa_science>
> >
> > To ensure compliance with legal requirements and to maintain cyber security 
> > standards, NIWA's IT systems are subject to ongoing monitoring, activity 
> > logging and auditing. This monitoring

Re: [CF-metadata] Surfaces under ice vs. above ice : sea water surface vs surface in standard names.

[Martin Juckes - UKRI STFC]

Dear Alison,


thanks, those names and definitions are good. I agree that they are ready to go 
into the standard name list,


regards,

Martin



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 29 May 2019 15:02
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: [CF-metadata] Surfaces under ice vs. above ice : sea water surface 
vs surface in standard names.

Dear Martin,

Thank you for reminding me about these proposals. I recall that we had some 
off-list discussion of these names in February before they were sent to the 
list.

(1) sea_water_pressure_at_sea_water_surface and
net_downward_shortwave_flux_at_sea_water_surface.

I agree with your suggestions to amend the definitions of these names by 
replacing 'The surface called "surface" means the lower boundary of the 
atmosphere' with 'The phrase "sea water surface" means the upper boundary of 
the liquid portion of an ocean or sea, including the boundary to floating ice 
if present.'

These changes are accepted and will be made in the June update to the standard 
name table.

(2)  Stresses at sea water surface

I agree with your proposals to introduce 4 new names for stresses at the upper 
surface of liquid sea water:
. downward_x_stress_at_sea_water_surface
. downward_y_stress_at_sea_water_surface
. downward_x_stress_correction_at_sea_water_surface
. downward_y_stress_correction_at_sea_water_surface.

Basing the units and definitions on existing names for surface stresses and 
stress corrections, the first two would be as follows.

downward_x_stress_at_sea_water_surface (Canonical units: Pa)
' "Downward" indicates a vector component which is positive when directed 
downward (negative upward). "x" indicates a vector component along the grid 
x-axis, positive with increasing x. A downward x stress is a downward flux of 
momentum towards the positive direction of the model's x-axis. The phrase "sea 
water surface" means the upper boundary of the liquid portion of an ocean or 
sea, including the boundary to floating ice if present.'

downward_y_stress_at_sea_water_surface (Canonical units: Pa)
' "Downward" indicates a vector component which is positive when directed 
downward (negative upward). "y" indicates a vector component along the grid 
y-axis, positive with increasing y. A downward y stress is a downward flux of 
momentum towards the positive direction of the model's y-axis. The phrase "sea 
water surface" means the upper boundary of the liquid portion of an ocean or 
sea, including the boundary to floating ice if present.'

We don't currently have any definition for 'stress_correction', but I borrowed 
from the one for 'flux_correction' in the following:

downward_x_stress_correction_at_sea_water_surface (Canonical units: Pa)
' "Downward" indicates a vector component which is positive when directed 
downward (negative upward). "x" indicates a vector component along the grid 
x-axis, positive with increasing x. A downward x stress is a downward flux of 
momentum towards the positive direction of the model's x-axis. A positive 
correction is downward i.e. added to the ocean. The phrase "sea water surface" 
means the upper boundary of the liquid portion of an ocean or sea, including 
the boundary to floating ice if present.'

downward_y_stress_correction_at_sea_water_surface (Canonical units: Pa)
' "Downward" indicates a vector component which is positive when directed 
downward (negative upward). "y" indicates a vector component along the grid 
y-axis, positive with increasing y. A downward y stress is a downward flux of 
momentum towards the positive direction of the model's y-axis. A positive 
correction is downward i.e. added to the ocean. The phrase "sea water surface" 
means the upper boundary of the liquid portion of an ocean or sea, including 
the boundary to floating ice if present.'

If you are happy with these, then I think all four can be accepted for 
inclusion in the standard name table.

Best wishes,
Alison

---
Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: Juckes, Martin (STFC,RAL,RALSP) 
Sent: 15 May 2019 11:59
To: CF-metadata (cf-metadata@cgd.ucar.edu) ; Pamment, 
Alison (STFC,RAL,RALSP) 
Subject: Re: Surfaces under ice vs. above ice : sea water surface vs surface in 
standard names.

Dear Alison,

could you take a look at the request for 4 terms listed below, which I 
submitted in February. There have been no other comments, but I think these are 
simple adjustments to existing names,

regards,
Martin


From: Juckes, Martin (STFC,RAL,RALSP)
Sent: 07 February 2019 17:16
To: CF-metadata (mailto:cf-metadata@cgd.ucar.edu)

Re: [CF-metadata] Volume fraction standard names

[Martin Juckes - UKRI STFC]

Dear Alison,


thanks, I agree with those definitions,


regards,

Martin



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 13 June 2019 14:58
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Volume fraction standard names

Dear Alison

Thanks, as ever. This all looks fine to me.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Thu, 13 Jun 2019 11:53:53 +
> From: Alison Pamment - UKRI STFC 
> To: "CF-metadata (cf-metadata@cgd.ucar.edu)" 
> Subject: [CF-metadata] Volume fraction standard names
>
> Dear Jonathan, Karl and Martin,
>
> Apologies for breaking off the earlier discussion of the volume_fraction 
> names. (The area_fraction changes were included in the May standard names 
> update).
>
> Most of the volume names are formulated as volume_fraction_of_X_in_Y where Y 
> is either 'soil' or 'sea_water'. The reason for my earlier suggestion was 
> that in a soil model or ocean model I would expect the volume of soil or 
> sea_water to be the same as the volume of the grid cell. However, Jonathan's 
> interpretation is more general and works even when Y does not occupy the full 
> grid cell volume, e.g, for soil pores or partial cells.
>
> I'd like to amend the suggested definition as follows:
> '"Volume fraction" is used in the construction volume_fraction_of_X_in_Y, 
> where X is a material constituent of Y. It is evaluated as the volume of X 
> divided by the volume of Y (including X). It may be expressed as a fraction, 
> a percentage, or any other dimensionless representation of a fraction.'
> This is similar to the mass_fraction definition and I think it would work for 
> 10 of the 11 existing names.
>
> The only name that follows a different pattern is ocean_volume_fraction. 
> Thank you Jonathan and Karl for providing guidance on this one - there seems 
> to be agreement that it is the fraction of the grid cell volume occupied by 
> sea-water. For this one I suggest the following:
> '"X_volume_fraction" means the fraction of grid box volume occupied by X. It 
> is evaluated as the volume of interest divided by the grid cell volume. It 
> may be expressed as a fraction, a percentage, or any other dimensionless 
> representation of a fraction. A data variable with standard name 
> ocean_volume_fraction is used to store the fraction of a grid cell underlying 
> sea-water, for example, where part of the grid cell is occupied by land or to 
> record ocean volume on a model's native grid following a regridding 
> operation.'
>
> The full list of names with amended definitions can be viewed in the CEDA 
> vocabulary editor: 
> http://cfeditor.ceda.ac.uk/proposals/1?status=active=volume_fraction2019=+and+display=Filter.
>  If you are happy with these changes, I think they can all be included in the 
> next update.
>
> Best wishes,
> Alison
>
> ---
> Alison Pamment Tel: 
> +44 1235 778065
> NCAS/Centre for Environmental Data AnalysisEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
>
> -Original Message-
> From: CF-metadata  On Behalf Of Jonathan 
> Gregory
> Sent: 24 April 2019 18:41
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
> area_fraction
>
> Dear Alison
>
> Thanks for your analysis. I agree with your proposal that we should define 
> consistently what we mean by the area and volume fractions.
>
> It seems to me that the 9 volume_fraction names are differently formulated 
> from the area_fraction names. With one exception, they all have the form 
> volume_fraction_of_X_in_Y. I take this to mean the volume of X is a subset of 
> the volume of Y. The case with X=clay and Y=soil has the same kind of 
> interpretation to the case with X=condensed_water and Y=soil_pores. Both X 
> and Y are volumes. The grid-box volume is not involved in the definition.
>
> The exception is ocean_volume_fraction. This is the only one which is like 
> the area_fractions. I think you're right that it means the fraction of the 
> grid-box volume which is ocean. This could differ from unity if the grid-box 
> is partly land (maybe some ocean models allow this) or if the ocean does not 
> occupy the entire thickness of the cell (i.e. part of it is the solid under- 
> lying the sea-water - certainly some models have such "partial cells").
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Alison Pamment - U

Re: [CF-metadata] order of product in standard name

[Martin Juckes - UKRI STFC]

Dear Alison,


Thank you, that is a good summary. I agree that it makes sense to treat 
"covariance" and "correlation" in the same way as "product".


Although these two terms appear in the guidelines, they don't yet appear in the 
standard name table itself, so the usage 
"covariance_over_longitude_of_northward_wind_and_air_temperature" will be a 
first for "covariance". Can we include a sentence in the description saying 
that "Covariance refers to the sample covariance rather than the population 
covariance"? I don't think it is likely that we will need to deal with 
population covariances in the CF standard name list, but, if we do, it would 
make sense to have a separate term for them.


Jonathan asked whether it would make better sense to use "covariance_wrt_..." 
rather than "convariance_over_". I think this would be an improvement: the 
covariance is an integral of a product and so using the same syntax as used for 
integrals makes sense here.


regards,

Martin



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 30 May 2019 14:12
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] order of product in standard name

Dear Jonathan and Martin,

I would like to make sure that we have fully resolved this issue as it affects 
names that are currently under discussion in two threads:
covariance_over_longitude_of_northward_wind_and_air_temperature (latest 
comment: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020922.html);
also:
  *   product_of_eastward_wind_and_lagrangian_tendency_of_air_pressure
  *   product_of_northward_wind_and_lagrangian_tendency_of_air_pressure
  *   product_of_lagrangian_tendency_of_air_pressure_and_specific_humidity
  *   product_of_lagrangian_tendency_of_air_pressure_and_air_temperature
  *   product_of_lagrangian_tendency_of_air_pressure_and_geopotential_height
(latest comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020927.html).

I agree with Jonathan that for covariance and correlation names it is better to 
have covariance_over_Z_of_X_and_Y, (rather than putting over_Z at the end as 
stated in the current guidelines). This is consistent with the way we now write 
integrals as integral_wrt_X_of_Y.

The current guidelines for correlation and covariance say simply that X and Y 
should be ordered alphabetically, whereas for product we have additional 
guidance: 'If X and Y are both scalars or both components of vectors, they are 
put in alphabetical order. If one of them is the component of a vector, it is 
put first i.e. the vector component is X, the scalar is Y.'

I think we are agreed that the same guidelines should apply to the ordering of 
X and Y in standard names for all commutative properties such as product, 
covariance, correlation, etc.

The rule about putting vector components first means that the covariance name 
as written above is in the correct order.

Regarding the lagrangian tendency names, I agree with Martin's argument that 
lagrangian_tendency_of_air_pressure should be regarded as a vertical component 
of the air velocity vector, rather than a scalar. Therefore it is correct to 
write the specific_humidity, air_temperature and geopotential_height names as 
above (this is the opposite way round to what was originally proposed).

I also agree with Martin's suggestion of ordering vector components as 
X=horizontal and Y=vertical when horizontal and vertical components are the 
operands. This is a useful general convention and gets around the problem of 
having product_of_eastward_wind_and_lagrangian_tendency_of_air_pressure and 
product_of_lagrangian_tendency_of_air_pressure_and_northward_wind which would 
arise from the alphabetical rule. (Of course if we are combining two horizontal 
or two vertical vector components we would still need to fall back on the 
alphabetical rule).

It is on my 'To Do' list in the next couple of months to conduct a thorough 
review of the standard names Guidelines document and the sections of the 
Conventions document covering standard names and units. They are all somewhat 
out of date. If we can agree these changes they can be included as part of that 
process.

Best wishes,
Alison

---
Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Jonathan 
Gregory
Sent: 10 May 2019 15:08
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] order of product in standard name

Dear all

I should have noticed that we already have a guideline about 
product_of_X_and_Y, which should also apply to covariance, correlation, and any 
other commutative function of X and Y:

 If X and Y are both scalars 

Re: [CF-metadata] New standard name - number_of_missing_observations

[Martin Juckes - UKRI STFC]

Dear Dan,


this looks like a sensible addition to me. There are other cases where we have 
names which have a degree of redundancy in the sense you describe, such as the 
"minus_X" names, for which the values could, obviously, be derived from "X". As 
I understand it the important question is whether a set of data values 
specifying the number of missing observations could be clearly labelled with 
existing CF metadata and the answer is that they cannot. Hence, I support 
adding this term,


regards,

Martin.


From: CF-metadata  on behalf of Hollis, Dan 

Sent: 20 May 2019 11:52:14
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New standard name - number_of_missing_observations

Dear all,

Many observation-based quantities are derived from a number of separate 
measurements e.g. a monthly precipitation total may be the sum of a series of 
daily values. In some cases the derived value is based on an incomplete set of 
constituent observations and it would be useful to record the amount of missing 
data. The number of measurements used to calculate a derived value is easily 
stored using the ‘number_of_observations’ standard name, but knowing how many 
observations there could have been is not so straightforward. In theory it 
could be worked out from the bounds of the time coordinate and information on 
the interval between the original measurements from the cell_methods attribute, 
however this is not especially user-friendly. I’d therefore like to propose the 
following new standard name:

Standard name: number_of_missing_observations
Canonical units: 1
Definition:
A variable with the standard name of number_of_missing_observations contains 
the number of discrete observations or measurements that were not available to 
derive the values of another data variable. The linkage between the data 
variable and the variable with a standard_name of 
number_of_missing_observations is achieved using the ancillary_variables 
attribute.

Comments welcome.

Regards,

Dan


Dan Hollis   Climatologist
Met Office   Hadley Centre   FitzRoy Road   Exeter   Devon   EX1 3PB   United 
Kingdom
Tel: +44 (0)1392 884535   Mob: +44 (0)7342058682   Fax: +44 (0)1392 885681
E-mail: dan.hol...@metoffice.gov.uk   
Website: http://www.metoffice.gov.uk
For UK climate and past weather information, visit 
http://www.metoffice.gov.uk/climate

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Dear Jonathan,


OK, flagged-dimension-array approach is certainly a more compact representation 
than my previous proposal (which had a flagged auxillary coordinate). It would 
certainly be an extension to the scope of the examples in the CF Conventions 
document. I have a slight concern that there might be a subtle conflict in 
terms of the way in which the "flag_meanings" are interpreted -- but I think 
that can be dealt with if we frame the description of new example carefully.


Firstly, it is perhaps relevant to clear up that "out_of_range" would not work 
in this case. The data in this bin is, I believe, a count of the profiles taken 
by the sensor for which the retrieval algorithm returned an error code rather 
than a height value. It is common practise to want an "out_of_range" bin in a 
histogram, but that is not the use case here. If we were recording the results 
from individual retrievals in a field with standard name "height", these data 
points would be flagged using the "missing_value" attribute.


In the existing examples of "flag_meanings" it appears that the status codes 
used are application specific, so there is perhaps no need to make a firm 
decision on the text used here ... though the example should make sense.


There are standard names which assert specific rules about the usage of 
"flag_meanings" -- we have discussed these in trac ticket 
153<https://cf-trac.llnl.gov/trac/ticket/153>. That discussion is not 
concluded, but the clear intention is that, for some names at least, the flag 
values/meanings mechanism should be used with "flag_meanings" which conform to 
the specification of the standard name. For example, if the standard name is 
"region", the "flag_meanings" values should come from the accepted list of 
region names.


In general, I think the "flag_meanings" should be consistent with the standard 
name. Perhaps we could express this as "The flag_meanings values should be 
consistent with the specifications of the standard name or, alternatively, when 
used in a coordinate array, represent status codes associated with data which 
would be reported as missing." With a clarification of this kind, I think the 
approach you are suggesting can work. This makes it clear that we are dealing 
with data points which would use the "missing_value" when recorded in a data 
array, but we have a different approach here because we are constructing a 
coordinate array to label data values, and the coordinate array has a label for 
missing values, not an missing value.


regards,

Martin





From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 15 May 2019 16:48
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Missing data bins in histograms

Dear Martin

Yes, that's what I meant, thanks. Indeed, I might be suggesting an extension
of the use of flag_values, because you're right that its existing uses are in
cases where every data value that occurs is one which appears in flag_values.
However this is not a requirement in the convention or conformance documents.

In your particular case, it is best to give the meaning as "missing"? It would
be more informative to call them "out of range", perhaps.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Tue, 14 May 2019 14:34:48 +
> From: Martin Juckes - UKRI STFC 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] Missing data bins in histograms
>
> Dear Jonathan,
>
>
> Sorry, I think I misunderstood the scope of valid usage of "flag_values". 
> I've only seen it used in contexts in which all values of the flagged array 
> are translated using the "flag_values"/"flag_meanings" pairs, but you are 
> suggesting, I think, that it should only apply to the one anomalous bin. If 
> we can use a single "flag_values" without changing the interpretation of the 
> rest of the array, that would make the solution easier.
>
>
> Does this correspond to what you are thinking of:
>
>
> float data(time,lat,lon,zbins);
>   data: standard_name =   
> "histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid";
>   data: coordinates="status";
> float zbins(zbins);
>   zbins: long_name="Height ranges (with bin for missing data at first 
> element)"
>   zbins: units="m";
>   zbins: bounds="zbin_bnds";
>   zbins: standard_name = "height";
>
>   zbins:flag_values =  -.f;
>   zbins:flag_meanings = "missing_values";
> float zbin_bnds(zindex,2);
> character status(char_len);
>status:standard_name = "status_flag";

Re: [CF-metadata] Surfaces under ice vs. above ice : sea water surface vs surface in standard names.

[Martin Juckes - UKRI STFC]

Dear Alison,


could you take a look at the request for 4 terms listed below, which I 
submitted in February. There have been no other comments, but I think these are 
simple adjustments to existing names,


regards,

Martin



From: Juckes, Martin (STFC,RAL,RALSP)
Sent: 07 February 2019 17:16
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Surfaces under ice vs. above ice : sea water surface vs surface in 
standard names.


Dear All,


while reviewing CMIP6 metadata specifications I came across a few anomalies 
regarding the distinction between the upper surface of the liquid ocean (which 
may be under ice) vs. the lower surface of the atmosphere (which would be above 
the ice).

(1) sea_water_pressure_at_sea_water_surface and
net_downward_shortwave_flux_at_sea_water_surface;

The names of these two terms suggest that they are intended to be different 
from, for example, surface_net_downward_shortwave_flux. They have been 
requested by OMIP for diagnostics which are intended to represent the air/sea 
or ice/sea interface, on the air/ice interface. The problem is that the 
descriptions use the standard phrase 'The surface called "surface" means the 
lower boundary of the atmosphere', which is wrong in this case. Can this be 
changed to: 'The phrase "sea water surface" means the upper boundary of the 
liquid portion of an ocean or sea, including the boundary to floating ice if 
present.'

(2) surface_downward_x/y_stress and surface_downward_x/y_stress_correction;

There is nothing wrong with these terms, but they have been wrongly used to 
represent stresses applied to the liquid ocean. To correct this we need four 
new terms. I propose using the "_at_sea_water_surface" construction, based on 
the two terms above:

  *   downward_x_stress_at_sea_water_surface
  *   downward_y_stress_at_sea_water_surface
  *   downward_x_stress_correction_at_sea_water_surface
  *   downward_y_stress_correction_at_sea_water_surface

As above, the description should include the sentence:
'The phrase "sea water surface" means the upper boundary of the liquid portion 
of an ocean or sea, including the boundary to floating ice if present.'

regards,
Martin


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Hi Dan,


if we were starting from a blank sheet, that would be a strong point. As it is, 
we are rather constrained by the existing practices in the community. I hope 
that we can find an agreement along the lines of the discussion that Jonathan 
and I are having which makes it possible to support this approach without major 
adjustment.


This is likely (if we succeed) to include presentation of a new example in the 
conventions document. Perhaps we could, at the same time, include and example 
showing the alternative approach which you are suggesting -- but  that would 
depend on having a standard name for the number of missing or rejected 
observations approved.


regards,

Martin



From: Hollis, Dan 
Sent: 14 May 2019 16:02
To: Juckes, Martin (STFC,RAL,RALSP); Gregory, Jonathan; 
cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: RE: [CF-metadata] Missing data bins in histograms

Hi Martin,

I agree there is no clear line between data and metadata and I didn't really 
intend to suggest there was one. As you say, there are different equally-valid 
views of where the line could/should be drawn in any particular situation 
between the different types of data that we wish to record. My instinct would 
be to separate the result of processing the available data (whether that be a 
mean, a total, a count or a histogram) from information about the data that was 
not available (such as a count of missing observations), but I appreciate that 
is not always necessary or practical.

Regards,

Dan


-Original Message-
From: Martin Juckes - UKRI STFC 
Sent: Tuesday, 14 May 2019 15:04
To: Hollis, Dan ; Gregory, Jonathan 
; cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: Re: [CF-metadata] Missing data bins in histograms

Hi Dan,


Thanks, that makes it clearer.


The conversation below follows on from one that Karl and I had with people from 
CFMIP (Cloud Forcing Model Intercomparison Project). The variable in question, 
contains the histogram, is produced to make it possible to compare climate 
model output with a standard product from the MISR imaging spectrometer.


I realise now that I have overlooked a change in the variable definition: 
although the product is computed as a histogram, the results are then 
normalised by total number of observations in each grid cell and reported as a 
percentage, so the actual variable name is 
cloud_area_fraction_in_atmosphere_layer rather than histogram. Their standard 
product has 16 bins: 15 for height ranges and one for the error flag.


When Karl and I started the conversation, one of us did suggest splitting the 
16th bin off into a separate variable, but this was considered as being an 
unwarranted complication: the variable is produced by one software package as a 
single array and used by a range of data analysis packages as a single array. 
Splitting it into two in the NetCDF file and then reassembling the parts 
afterwards would create significant extra work that nobody wants to do.


A considerable volume of data has already been written in the CMIP5 archive 
using this approach, with no CF metadata to inform people of the special nature 
of the 16th bin: the aim here is to improve on that state of affairs by 
providing specific metadata.


I would say that your view of the count of missing values as ancillary data is 
a valid perspective, but the suggestion that you are able to draw a clear line 
between "data" and "metadata" and that this perspective should become standard 
is not tenable. The perspective that counts of error flags are just as much 
data as counts of the other height range bins is also valid.


regards,

Martin



From: Hollis, Dan 
Sent: 14 May 2019 13:47
To: Juckes, Martin (STFC,RAL,RALSP); Gregory, Jonathan; 
cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: RE: [CF-metadata] Missing data bins in histograms

Hi Martin,

Sorry, I didn't mean to imply that we would do away with the histogram standard 
names - these would be retained, of course. I just meant that we both want to 
store one extra bit of information (maximum number of obs or, equivalently, 
missing number of obs) and that in both use cases ('histogram_of...' and 
'number_of...') this could be in an ancillary variable, for which we'd need a 
new standard name. Does that make more sense?

I appreciate that your users wish to display the number of missing values 
alongside the counts for the different bins, however I'd argue that this 
information is ancillary to the histogram itself (in the same way that the 
number of missing days is ancillary to a count of days of air frost) and should 
be stored as such in the netCDF file (rather than in a 'pseudo-bin').

Regards,

Dan


-Original Message-
From: Martin Juckes - UKRI STFC 
Sent: Tuesday, 14 May 2019 13:29
To: Hollis, Dan ; Gregory, Jonathan 
; cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: Re: [CF-metadat

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Dear Jonathan,


Sorry, I think I misunderstood the scope of valid usage of "flag_values". I've 
only seen it used in contexts in which all values of the flagged array are 
translated using the "flag_values"/"flag_meanings" pairs, but you are 
suggesting, I think, that it should only apply to the one anomalous bin. If we 
can use a single "flag_values" without changing the interpretation of the rest 
of the array, that would make the solution easier.


Does this correspond to what you are thinking of:


float data(time,lat,lon,zbins);
  data: standard_name =   
"histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid";
  data: coordinates="status";
float zbins(zbins);
  zbins: long_name="Height ranges (with bin for missing data at first element)"
  zbins: units="m";
  zbins: bounds="zbin_bnds";
  zbins: standard_name = "height";

  zbins:flag_values =  -.f;
  zbins:flag_meanings = "missing_values";
float zbin_bnds(zindex,2);
character status(char_len);
   status:standard_name = "status_flag";
   status:long_name = "Flag indicating quality of histogram";
float lat(lat);
float lon(lon);

data:
  zbins = -., 25., 100., ;
  zbin_bnds = -.,0., 0., 50., 50., 150., ...

regards,
Martin

From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 14 May 2019 13:43
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Missing data bins in histograms

Dear Martin

I agree that if valid_range implies masked-out data in some software, we can't
put special values out of the range, and that we shouldn't tamper with missing
data. I still think that flag_values is a better way to indicate special
values in a coordinate variable than an auxiliary coordinate variable would be.
If there are flag values, by definition those values aren't physical coordinate
values, and the user of such data need to be aware of that. That would be the
consequence of changing the convention to allow flag_values for coordinate
variables, just as it is presently the case that a user of a data variable
ought to check whether it has flag_values, which would likewise indicate that
some of the valid values are not actually physical values. However I don't
think we ought to change the standard_name to signal it, since introducing new
standard_names requires software to recognise both versions.

Best wishes

Jonathan

----- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Tue, 14 May 2019 09:03:19 +
> From: Martin Juckes - UKRI STFC 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] Missing data bins in histograms
>
> Dear Jonathan,
>
>
> I looked at "valid_range", and also "actual_range", but I believe that the 
> definitions of either of these would have to be changed to accommodate this 
> usage, and we would run into the problem that Jim raised in connection with 
> my earlier suggestion of using "missing_value": such changes can break 
> assumptions made by existing software. Data outside the "valid_range" may 
> well be automatically rejected by a user application before the data gets to 
> any CF aware libraries. For instance, python netCDF4 at version 1.3.0 and 
> 1.3.1 automatically removes data outside the valid_range, giving the user a 
> masked array.  There is some discussion of this here: 
> https://github.com/Unidata/netcdf4-python/issues/748.
>
>
> <https://github.com/Unidata/netcdf4-python/issues/748>It is possible to 
> circumvent this behaviour by changing the auto-masking setting in python 
> netCDF4, and the NUG does suggest using values outside the "valid_range" as 
> flags. NUG also suggests using the missing_value attribute to list such flag 
> values ... but Jim has pointed out that such an approach is likely to cause 
> problems with many applications. This is a complex area because the meaning 
> of "missing_value" in NUG has evolved. Up until CF 1.5 it appears that a 
> "missing_value" meant, unambiguously, missing data.  The current CF appears 
> to changed this in line with NUG so that different usages are now 
> permissible, but I still agree with Jim's objection. We can't, I'm sure, at 
> this stage, follow an approach which depends on users being able to control 
> the auto-masking settings (it is a simple call to the "set_auto_mask" method 
> if you are using the python netCDF4 library directly ... but may not be 
> available to users who are working with applications built on the library).
>
>
> I wanted to use a new standard name for the hight bins because of the fact 
> that the value in the first bin, which I have set to -., is not a h

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Hi Dan,


Thanks, that makes it clearer.


The conversation below follows on from one that Karl and I had with people from 
CFMIP (Cloud Forcing Model Intercomparison Project). The variable in question, 
contains the histogram, is produced to make it possible to compare climate 
model output with a standard product from the MISR imaging spectrometer.


I realise now that I have overlooked a change in the variable definition: 
although the product is computed as a histogram, the results are then 
normalised by total number of observations in each grid cell and reported as a 
percentage, so the actual variable name is 
cloud_area_fraction_in_atmosphere_layer rather than histogram. Their standard 
product has 16 bins: 15 for height ranges and one for the error flag.


When Karl and I started the conversation, one of us did suggest splitting the 
16th bin off into a separate variable, but this was considered as being an 
unwarranted complication: the variable is produced by one software package as a 
single array and used by a range of data analysis packages as a single array. 
Splitting it into two in the NetCDF file and then reassembling the parts 
afterwards would create significant extra work that nobody wants to do.


A considerable volume of data has already been written in the CMIP5 archive 
using this approach, with no CF metadata to inform people of the special nature 
of the 16th bin: the aim here is to improve on that state of affairs by 
providing specific metadata.


I would say that your view of the count of missing values as ancillary data is 
a valid perspective, but the suggestion that you are able to draw a clear line 
between "data" and "metadata" and that this perspective should become standard 
is not tenable. The perspective that counts of error flags are just as much 
data as counts of the other height range bins is also valid.


regards,

Martin



From: Hollis, Dan 
Sent: 14 May 2019 13:47
To: Juckes, Martin (STFC,RAL,RALSP); Gregory, Jonathan; 
cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: RE: [CF-metadata] Missing data bins in histograms

Hi Martin,

Sorry, I didn't mean to imply that we would do away with the histogram standard 
names - these would be retained, of course. I just meant that we both want to 
store one extra bit of information (maximum number of obs or, equivalently, 
missing number of obs) and that in both use cases ('histogram_of...' and 
'number_of...') this could be in an ancillary variable, for which we'd need a 
new standard name. Does that make more sense?

I appreciate that your users wish to display the number of missing values 
alongside the counts for the different bins, however I'd argue that this 
information is ancillary to the histogram itself (in the same way that the 
number of missing days is ancillary to a count of days of air frost) and should 
be stored as such in the netCDF file (rather than in a 'pseudo-bin').

Regards,

Dan


-Original Message-
From: Martin Juckes - UKRI STFC 
Sent: Tuesday, 14 May 2019 13:29
To: Hollis, Dan ; Gregory, Jonathan 
; cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: Re: [CF-metadata] Missing data bins in histograms

Hi Dan,


it is a similar concept, but the aim here is to record it in a histogram. We 
have a standard name for the histogram  .. I'm not sure why you think we need 
to change this. Perhaps it would be possible to do away with "histogram_" 
standard names and just use "number_of_observations", but I'm afraid I don't 
see much merit in that approach.


For you use case, I can certainly see that there could be a case for a 
"number_of_missing_observations" standard name, but it doesn't help with the 
specification of the histogram that I want to store.


regards,

Martin


From: Hollis, Dan 
Sent: 14 May 2019 13:13
To: Juckes, Martin (STFC,RAL,RALSP); Gregory, Jonathan; 
cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: RE: [CF-metadata] Missing data bins in histograms

Hi Martin,

Thanks for your suggestion - I can see how this could work for our data. 
However I can also see that having to parse the 'interval' text from the 
'cell_methods' comment field and combine that with the bounds from the time 
coordinate is not especially user-friendly! It would be much easier if we could 
store 'maximum_number_of_observations' (or 'number_of_missing_observations') as 
well.

I guess the reason your suggestion does not work for your histograms is that 
there is no obvious place to record the sampling intervals (angular and 
distance) of the radar data. However, if I'm understanding this correctly, all 
the user really needs is the total number of data bins in one sweep of the 
radar. I'd argue that this is similar in concept to 
'maximum_number_of_observations' i.e. maybe we just need a new standard name 
that we can both use. What do you think?

Apologies if I haven't fully gra

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Hi Dan,


it is a similar concept, but the aim here is to record it in a histogram. We 
have a standard name for the histogram  .. I'm not sure why you think we need 
to change this. Perhaps it would be possible to do away with "histogram_" 
standard names and just use "number_of_observations", but I'm afraid I don't 
see much merit in that approach.


For you use case, I can certainly see that there could be a case for a 
"number_of_missing_observations" standard name, but it doesn't help with the 
specification of the histogram that I want to store.


regards,

Martin


From: Hollis, Dan 
Sent: 14 May 2019 13:13
To: Juckes, Martin (STFC,RAL,RALSP); Gregory, Jonathan; 
cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: RE: [CF-metadata] Missing data bins in histograms

Hi Martin,

Thanks for your suggestion - I can see how this could work for our data. 
However I can also see that having to parse the 'interval' text from the 
'cell_methods' comment field and combine that with the bounds from the time 
coordinate is not especially user-friendly! It would be much easier if we could 
store 'maximum_number_of_observations' (or 'number_of_missing_observations') as 
well.

I guess the reason your suggestion does not work for your histograms is that 
there is no obvious place to record the sampling intervals (angular and 
distance) of the radar data. However, if I'm understanding this correctly, all 
the user really needs is the total number of data bins in one sweep of the 
radar. I'd argue that this is similar in concept to 
'maximum_number_of_observations' i.e. maybe we just need a new standard name 
that we can both use. What do you think?

Apologies if I haven't fully grasped the complexities of your data.

Regards,

Dan

-----Original Message-----
From: Martin Juckes - UKRI STFC 
Sent: Tuesday, 14 May 2019 12:02
To: Hollis, Dan ; Gregory, Jonathan 
; cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: Re: [CF-metadata] Missing data bins in histograms

Hello Dan,


I think there is a method for recording the number of valid observations in 
each data point, which, if I've understood correctly, would meet the 
requirement you are describing: using an "ancillary_variable" with standard 
name "number_of_observations".  I don't think there is a method for explicitly 
recording missing values, but you can use "interval" (in the "cell_methods" 
comment) to specify the interval of input data which, together with the 
duration of the calculation, will tell you the maximum amount of input values 
available.


In your use-case the number of missing values would be part of the ancillary 
information, in my use case it is the data itself -- the users want a histogram 
which includes a count of failed retrievals,


regards,

Martin


From: Hollis, Dan 
Sent: 14 May 2019 11:22
To: Juckes, Martin (STFC,RAL,RALSP); Gregory, Jonathan; 
cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: RE: [CF-metadata] Missing data bins in histograms

Dear Martin/Jonathan/Jim,

I appreciate that this discussion is focussed on histograms, however I wonder 
if there is a wider issue here i.e. how should one record the number of missing 
values for any extensive quantity?

For example, we use number_of_days_with_air_temperature_below_threshold to 
store counts of days of air frost (computed from station observations of daily 
minimum temperature). The threshold is specified using a scalar coordinate 
variable called 'air_temperature' with a value of 0.0. The counts of air frost 
are for periods of months, seasons or years and, inevitably, the values for 
some periods for some stations are based on incomplete data. Is there a 
recommended method for recording the number of missing observations for each 
data point (apologies if I've missed this in the conventions)? If so then maybe 
the same approach could be used for histograms too. If not then my feeling is 
that whatever solution you propose should be applicable to all extensive 
quantities (i.e. all quantities that can be derived from a set of constituent 
observations). Having a special 'bin' might work for histogram data but would 
not work for other variables so I think a different approach is required.

My feeling is that the number of missing values is sort of like metadata i.e. 
it's telling you something about the quality of the data itself. Would an 
ancillary variable suit this purpose?

Regards,

Dan


-----Original Message-
From: CF-metadata  On Behalf Of Martin Juckes 
- UKRI STFC
Sent: Tuesday, 14 May 2019 10:03
To: Gregory, Jonathan ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Missing data bins in histograms

Dear Jonathan,


I looked at "valid_range", and also "actual_range", but I believe that the 
definitions of either of these would have to be changed to accommodate this 
usage, and we wou

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Hello Dan,


I think there is a method for recording the number of valid observations in 
each data point, which, if I've understood correctly, would meet the 
requirement you are describing: using an "ancillary_variable" with standard 
name "number_of_observations".  I don't think there is a method for explicitly 
recording missing values, but you can use "interval" (in the "cell_methods" 
comment) to specify the interval of input data which, together with the 
duration of the calculation, will tell you the maximum amount of input values 
available.


In your use-case the number of missing values would be part of the ancillary 
information, in my use case it is the data itself -- the users want a histogram 
which includes a count of failed retrievals,


regards,

Martin


From: Hollis, Dan 
Sent: 14 May 2019 11:22
To: Juckes, Martin (STFC,RAL,RALSP); Gregory, Jonathan; 
cf-metadata@cgd.ucar.edu; jbi...@cicsnc.org
Subject: RE: [CF-metadata] Missing data bins in histograms

Dear Martin/Jonathan/Jim,

I appreciate that this discussion is focussed on histograms, however I wonder 
if there is a wider issue here i.e. how should one record the number of missing 
values for any extensive quantity?

For example, we use number_of_days_with_air_temperature_below_threshold to 
store counts of days of air frost (computed from station observations of daily 
minimum temperature). The threshold is specified using a scalar coordinate 
variable called 'air_temperature' with a value of 0.0. The counts of air frost 
are for periods of months, seasons or years and, inevitably, the values for 
some periods for some stations are based on incomplete data. Is there a 
recommended method for recording the number of missing observations for each 
data point (apologies if I've missed this in the conventions)? If so then maybe 
the same approach could be used for histograms too. If not then my feeling is 
that whatever solution you propose should be applicable to all extensive 
quantities (i.e. all quantities that can be derived from a set of constituent 
observations). Having a special 'bin' might work for histogram data but would 
not work for other variables so I think a different approach is required.

My feeling is that the number of missing values is sort of like metadata i.e. 
it's telling you something about the quality of the data itself. Would an 
ancillary variable suit this purpose?

Regards,

Dan


-Original Message-
From: CF-metadata  On Behalf Of Martin Juckes 
- UKRI STFC
Sent: Tuesday, 14 May 2019 10:03
To: Gregory, Jonathan ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Missing data bins in histograms

Dear Jonathan,


I looked at "valid_range", and also "actual_range", but I believe that the 
definitions of either of these would have to be changed to accommodate this 
usage, and we would run into the problem that Jim raised in connection with my 
earlier suggestion of using "missing_value": such changes can break assumptions 
made by existing software. Data outside the "valid_range" may well be 
automatically rejected by a user application before the data gets to any CF 
aware libraries. For instance, python netCDF4 at version 1.3.0 and 1.3.1 
automatically removes data outside the valid_range, giving the user a masked 
array.  There is some discussion of this here: 
https://github.com/Unidata/netcdf4-python/issues/748.


<https://github.com/Unidata/netcdf4-python/issues/748>It is possible to 
circumvent this behaviour by changing the auto-masking setting in python 
netCDF4, and the NUG does suggest using values outside the "valid_range" as 
flags. NUG also suggests using the missing_value attribute to list such flag 
values ... but Jim has pointed out that such an approach is likely to cause 
problems with many applications. This is a complex area because the meaning of 
"missing_value" in NUG has evolved. Up until CF 1.5 it appears that a 
"missing_value" meant, unambiguously, missing data.  The current CF appears to 
changed this in line with NUG so that different usages are now permissible, but 
I still agree with Jim's objection. We can't, I'm sure, at this stage, follow 
an approach which depends on users being able to control the auto-masking 
settings (it is a simple call to the "set_auto_mask" method if you are using 
the python netCDF4 library directly ... but may not be available to users who 
are worki
 ng with applications built on the library).


I wanted to use a new standard name for the hight bins because of the fact that 
the value in the first bin, which I have set to -., is not a height. This 
data point needs to have a valid floating point value to conform to the rules 
for a coordinate array, but, unlike the rest of the array, it should not be 
interpreted as height. This is signalled by the presence of an auxiliary 
c

Re: [CF-metadata] Some standard name updates to improve consistency.

[Martin Juckes - UKRI STFC]

Hello Alison,


I would like to return to the "product_of" terms because Jonathan has, in 
another thread, drawn attention to the guidelines on the ordering of "X" and 
"Y" in "product_of_X_and_Y", namely:


If X and Y are both scalars or both components of vectors, they are put in 
alphabetical order. If one of them is the component
 of a vector, it is put first i.e. the vector component is X, the scalar is Y. 
(http://cfconventions.org/Data/cf-standard-names/docs/guidelines.html)


The terms we have discussed below involve products of the 
"lagrangian_tendency_of_air_pressure" .. which I would interpret as the 
vertical component of the velocity vector in pressure coordinates. I am not 
convinced that it appropriate to follow the guidelines rigidly here, as that 
would imply  product_of_eastward_wind_and_lagrangian_tendency_of_air_pressure 
and product_of_lagrangian_tendency_of_air_pressure_and_northward_wind. It would 
surely be better to use the ordering (1) horizontal, (2) vertical for these 
terms.


-- This specific problem goes away if we regard

"lagrangian_tendency_of_air_pressure"
as a scalar .. but we run into a similar issue with terms such as 
product_of_geopotential_height_and_lagrangian_tendency_of_air_pressure and 
product_of_lagrangian_tendency_of_air_pressure_and_specific_humidity. These are 
essentially advective fluxes, so I believe we should place the air pressure 
tendency first.


This would improve consistency with existing terms such as 
product_of_upward_air_velocity_and_air_temperature.


I.e. I suggest the following names ... the first two as you approved earlier, 
and the last 3 reversing the order of "X" and "Y":

  *   product_of_eastward_wind_and_lagrangian_tendency_of_air_pressure
  *   product_of_northward_wind_and_lagrangian_tendency_of_air_pressure
  *   product_of_lagrangian_tendency_of_air_pressure_and_specific_humidity
  *   product_of_lagrangian_tendency_of_air_pressure_and_air_temperature
  *   product_of_lagrangian_tendency_of_air_pressure_and_geopotential_height

regards,
Martin



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 09 May 2019 13:56
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Some standard name updates to improve consistency.

Dear Martin

OK. Thanks for explaining and sorry I didn't notice the correct point. I am
happy then.

Best wishes

Jonathan

On Thu, May 09, 2019 at 12:26:40PM +, Martin Juckes - UKRI STFC wrote:
> Date: Thu, 9 May 2019 12:26:40 +
> From: Martin Juckes - UKRI STFC 
> To: Jonathan Gregory ,
>  "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] Some standard name updates to improve
>  consistency.
>
> Dear Jonathan,
>
>
> On the question of the use of the phrase "ambient_aerosol" when referring to 
> the aerosol itself, rather than to the particles within the aerosol, I fear 
> that my comment which you quote may have become detached from the intended 
> context.
>
>
> I am happy with the distinction between "aerosol" (the suspension of particle 
> in air) and "aerosol_particles" (the particles which are suspended). My 
> comment to Alison referred to the use of the qualifier "ambient" when talking 
> about the aerosol itself: is it necessary or useful?
>
>
> The issue cam up because there are 5 standard names using the phrase 
> "dust_ambient_aerosol_particles_direct_radiative_effect" which I suggested 
> changing to "dust_aerosol_direct_radiative_effect". This would be consistent 
> with the usage in the literature, which would, I believe, make the terms 
> easier to read. In this case, there is nothing wrong with referring to the 
> aerosol suspension. Alison agreed with these points, but would like to retain 
> "ambient", as in "dust_ambient_aerosol_direct_radiative_effect". When talking 
> about particles within an aerosol it is very important to distinguish between 
> measurements representative of their state in the atmospheric suspension vs. 
> the state they might be in after sampling. "ambient", when qualifying 
> "aerosol_particles", means that we are describing the particles as they exist 
> in the aerosol. As a qualification of "aerosol" I can't see that it has any 
> meaning.
>
>
> The 4 terms which you refer to using "aerosol" rather than 
> "aerosol_particles" are ones which Alison agreed to change to include 
> "particles" earlier in this thread. These are all terms which are clearly 
> intended to refer only to the particles.
>
>
> regards,
>
> Martin
>
>
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 07 May 2019 1

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Dear Jim, Jonathan,


OK, I accept your point that this would be a new meaning of "missing_value", 
and that probably causes more serious problems than the one we are trying to 
solve.


I believe that Jonathan is also correct in saying that we can't use flag_values 
for this purpose without a change in the convention ... but perhaps we should 
explore whether such a change would lead to a good solution. Do you have a 
specific proposal in mind?


If not, here is an idea adapted from my last post. In this example I have used 
a real valued dimension coordinate to define the data bins, with an arbitrary 
value in the first bin. The new feature is an auxiliary coordinate which is 
constructed to label the first bin as "missing_data" and the remaining bins as 
"data".


I believe that it would be mis-leading to use the existing standard name 
"height" for the variable "zbins" in this example, because the first bin is not 
a height range. Hence, I suggest introducing a new standard name "height_bins" 
which would allow one or more bins to have special meanings which should be 
indicated by a string valued auxiliary coordinate.


"zbin_flags" could also be encoded as a character array, with values 
["missing_values", "data", "data", ..]. This could be done without changing 
the convention text, since character arrays are allowed auxiliary coordinate. 
However, I believe that it would be worth making an adjustment here, since the 
use of flags seems more natural.


I've given the "zbin_flags" a new standard name "bin_status_flag", which is 
related to the existing term "status_flag", but refers to the status of the 
data being counted in the histogram rather than to the status of the histogram 
itself. This allows us to refer unambiguously to the fact that we are counting 
missing data in the first bin.


Would this work?


float data(time,lat,lon,zbins);

  data: standard_name =   
"histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid";

  data: coordinates="zbin_flags status";

float zbins(zbina);

  zbins: long_name="Height ranges (with bin for missing data at first element)"

  zbins: units="m";

  zbins: bounds="zbin_bnds";

  zbins: standard_name = "height_bins";

float zbin_bnds(zindex,2);

integer zbin_flags(zbins);

   zbin_flags: long_name = "Flags indicating the status of data which is 
counted in each bin";

   zbin_flags:standard_name = "bin_status_flag";

   zbin_flags:flag_values = 0,1;

   zbin_flags:flag_meanings = "missing_values data";

character status(char_len);

   status:standard_name = "status_flag";

   status:long_name = "Flag indicating quality of histogram";

float lat(lat);

float lon(lon);


data:

  zbins = -., 25., 100., ;

  zbin_bnds = -.,0., 0., 50., 50., 150., ...

  zbin_flags = 0,1,1,1,...


Regards,
Martin


From: CF-metadata  on behalf of Jim Biard 

Sent: 10 May 2019 15:58
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Missing data bins in histograms


Hi.

Sorry I have been so quiet lately. I've been caught up in other activities.

I have a strong aversion to the proposal to overload the missing_value 
attribute with a wholly different meaning. Using missing_value in this way will 
produce unexpected results in a number of existing software packages. If the 
minor modification to CF to designate flag attributes to be used on coordinate 
variables doesn't seem like an acceptable solution for one reason or another, I 
think we should define a new convention that doesn't add contradictory 
interpretations of existing attributes.

Grace and peace,

Jim

On 5/2/19 11:49 AM, Martin Juckes - UKRI STFC wrote:

Dear Jonathan, Jim,



I’m sorry to have dropped this conversation after starting it three years ago. 
We ended up not fixing the problem for CMIP6, but I think it is worth taking 
another look.



Coming back to it again, I think that a variation on Jim’s suggestion could 
work: rather than using flags it should be possible to use a coordinate 
variable, as is done for some CMIP variables that have region names along one 
axis. The NetCDF  dimension would be an index, and the array of values defining 
the bins would be an auxiliary coordinate which, I believe, is not subject to 
the rules on monotonicity and missing values which apply to NetCDF dimensions. 
There may be a need for some clarifications, but I think this approach would be 
much closer to the current convention that any change in the specification for 
non-auxiliary coordinate variables.


We have a specific use case in CMIP6 for which the bins are height bins (height 
of detected cloud), with one bin reserved for "retri

Re: [CF-metadata] Fwd: Fwd: Re: Standard name of isobaric zonal mean eddy meridional temperature advection

[Martin Juckes - UKRI STFC]

Hello All,


I'm happy with that:


covariance_over_longitude_of_northward_wind_and_air_temperature,


with the understanding, which should be mentioned in the description, that the 
variable should be used with a vertical coordinate and the covariance over 
longitude should be taken along iso-surfaces of that vertical coordinate.


Regards,

Martin




From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 10 May 2019 00:16:55
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Fwd: Fwd: Re: Standard name of isobaric zonal mean 
eddy meridional temperature advection

With that fix, I'm happy with Jonathan's suggestion.
Karl

On 5/9/19 10:03 AM, Jonathan Gregory wrote:
> Actually it should be northward_wind, not northward_velocity.
>
> - Forwarded message from Jonathan Gregory 
> Date: Thu, 9 May 2019 18:02:32 +0100
>
> Dear Martin et al.
>
> Is it sum_x (v'(x) T'(x)) where v'=v-avg_x(v), similarly for T, and x is
> longitude? In that case I think it would be neat to describe it as a
> covariance, which like "product" doesn't attribute a physical meaning to it.
> Could it be called
>covariance_over_longitude_of_northward_velocity_and_air_temperature
> where the (important) fact that it is calculated on pressure levels can be
> adequately indicated by its having a coordinate of pressure, I think. The
> same quantity could be computed on other sorts of levels.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Martin Juckes - UKRI STFC 
>  -
>
>> PS: Michaela sent another suggestion while I was composing that email:
>>
>>
>> covariance_of_northward_velocity_and_temperature .. which could work, though 
>> I think it would need a prefix of "zonal_isobaric".
>>
>> regards,
>> Martin
>>
>>
>>
>>
>> 
>> From: Juckes, Martin (STFC,RAL,RALSP)
>> Sent: 08 May 2019 09:55
>> To: CF-metadata (cf-metadata@cgd.ucar.edu)
>> Cc: Plummer, David (EC); David Neubauer; sen...@meteo.fr; RIGOUDY Gaelle; 
>> Michael Schulz; Michaela Hegglin; Taylor, Karl E.
>> Subject: Standard name of isobaric zonal mean eddy meridional temperature 
>> advection
>>
>>
>> Hello All,
>>
>>
>> For AerChemMIP we need a new standard name for a quantity which is the 
>> isobaric zonal mean of the eddy meridional temperature advection. That is, 
>> the mean wrt. longitude of the product of v' and T', where v' and T' are the 
>> eddy meridional velocity and air temperature respectively and "eddy" denotes 
>> the departure from the isobaric zonal mean. The units should be "K m s-1"
>>
>>
>> This is related to two existing terms:
>>
>>1.  northward_heat_flux_in_air_due_to_eddy_advection  [W m-2]
>>2.  product_of_northward_wind_and_air_temperature  [K m s-1]
>>
>> The first of these involves the eddy advection, but includes a factor of 
>> density and the specific heat constant. Since density is spatially varying, 
>> (1) can not be directly converted to the term we want, though there is an 
>> approximate relationship.
>>
>> The second specifies the product, but without reference to the eddies.
>>
>> The term "eddy_advection" occurs in 38 existing terms, always in the form 
>> "_due_to_[...]eddy_advection", describing the part of some process which 
>> can be attributed to some kind of eddy advection.  In this case we want a 
>> term for the eddy advection itself.
>>
>> In some preliminary discussion we have the following ideas:
>>
>> (1) 
>> northward_heat_flux_expressed_as_temperature_flux_in_air_due_to_eddy_advection
>>  -- staying close to the existing heat flux term;
>> (2) northward_temperature_flux_in_air_due_to_eddy_advection -- more 
>> descriptive
>> (3) Karl has suggested terms based on "product_of_...", to avoid the use of 
>> "temperature flux", because the notion of "flux" sits uncomfortably with a 
>> non-conservative quantity like temperature.
>>
>> In reviewing the use of "eddy_advection" in existing terms, I can see that 
>> the nature of the eddy advection is clearly defined in 27 of them, and the 
>> heat flux term above is the only one for which the user is left to guess. 
>> The standard interpretation would be as a departure from the isobaric zonal 
>> mean, but that is not spelled out in the standard name.
>>
>> Combining some of the ideas from Karl and Michaela (suggestion 2 above), I 
>> think we could use:
>>
>>
>>*   northward_iso

Re: [CF-metadata] Some standard name updates to improve consistency.

[Martin Juckes - UKRI STFC]

Dear Jonathan,


On the question of the use of the phrase "ambient_aerosol" when referring to 
the aerosol itself, rather than to the particles within the aerosol, I fear 
that my comment which you quote may have become detached from the intended 
context.


I am happy with the distinction between "aerosol" (the suspension of particle 
in air) and "aerosol_particles" (the particles which are suspended). My comment 
to Alison referred to the use of the qualifier "ambient" when talking about the 
aerosol itself: is it necessary or useful?


The issue cam up because there are 5 standard names using the phrase 
"dust_ambient_aerosol_particles_direct_radiative_effect" which I suggested 
changing to "dust_aerosol_direct_radiative_effect". This would be consistent 
with the usage in the literature, which would, I believe, make the terms easier 
to read. In this case, there is nothing wrong with referring to the aerosol 
suspension. Alison agreed with these points, but would like to retain 
"ambient", as in "dust_ambient_aerosol_direct_radiative_effect". When talking 
about particles within an aerosol it is very important to distinguish between 
measurements representative of their state in the atmospheric suspension vs. 
the state they might be in after sampling. "ambient", when qualifying 
"aerosol_particles", means that we are describing the particles as they exist 
in the aerosol. As a qualification of "aerosol" I can't see that it has any 
meaning.


The 4 terms which you refer to using "aerosol" rather than "aerosol_particles" 
are ones which Alison agreed to change to include "particles" earlier in this 
thread. These are all terms which are clearly intended to refer only to the 
particles.


regards,

Martin



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 07 May 2019 18:19
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Some standard name updates to improve consistency.

Dear Martin and Alison

Thank you for carefully pursuing this detailed discussion. The degree of
consistency which Martin remarked upon initially is encouraging, but it's also
evident that we have to work very hard to achieve that, and any tools that we
can put in place to make it easier (as Martin is thinking about, I believe)
are well worth considering.

I have some small points.

>   1.  I've looked into the elemental/black carbon issue briefly
...
> it may make sense to deal with that in a separate discussion and try to get 
> some relevant experts involved.

I agree with that conclusion.

> 9. I'm still a little uncomfortable with the idea of "ambient_aerosol" 
> referring to the suspension of particles in air. The phrase 
> "ambient_aerosol_particles" is used when we are referring to properties of 
> the particles rather than the suspension

This is like the distinction between ocean vs sea_water and atmosphere vs air.

> I can't think of a meaningful interpretation of a "dry aerosol" (I think 
> dust_dry_aerosol is only used in the form dust_dry_aerosol_particles).

We have the following names which mention dry_aerosol without particles:

mass_concentration_of_biomass_burning_dry_aerosol_in_air
mass_fraction_of_mercury_dry_aerosol_in_air
tendency_of_atmosphere_mass_content_of_mercury_dry_aerosol_due_to_emission
tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur_due_to_wet_deposition

> For "relative_humidity_for_aerosol_particle_size_selection", I recognise that 
> this would be the only use of "particle" in the singular.

This is a minor concern, but to avoid introducing it in the singular we could
write relative_humidity_for_size_selection_of_aerosol_particles - that might
be easier to read as well.

> I suggest we add 'A positive radiative forcing or radiative effect is
equivalent to a downward radiative flux and contributes to a warming of the
earth system.'

I agree that for the sake of clarity it would be good to add this. It's
consistent with literature, as you say, and also with the IPCC AR5 glossary,
which says, "Radiative forcing is the change in the net, downward minus upward,
radiative flux ...".

Best wishes

Jonathan
___
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

Re: [CF-metadata] Standard name of isobaric zonal mean eddy meridional temperature advection

[Martin Juckes - UKRI STFC]

 s-1].
>
> Also, by “eddy_advection”,  people do mean deviations from the instantaneous 
> zonal mean.
>
> If it doesn’t sound like changing the name is a good idea, we could simply 
> change the units to [K m s-1], and explain that v’T’ was intended?
>
> This is what people expect to deliver for this variable as Gaelle’s case 
> shows too.
>
>
> Michaela
>
>
>
>
>> On 7 May 2019, at 09:30, Martin Juckes - UKRI STFC 
>>  wrote:
>>
>> Hi Karl,
>>
>>
>> It would need a new standard name .. perhaps :
>>
>>
>> northward_heat_flux_expressed_as_temperature_flux_in_air_due_to_eddy_advection
>>
>>
>> -- this is the current name with "_expressed_as_temperature_flux" inserted. 
>> It would make it clear that it is closely related to 
>> northward_heat_flux_in_air_due_to_eddy_advection, but also provide the 
>> necessary level of detail for CF.
>>
>>
>> The relationship between the two is not a simple transformation of units: 
>> you need to make an assumption about the density and heat capacity of the 
>> air (if this is done after the fact it will, I believe, involve some degree 
>> of approximation).
>>
>>
>> regards,
>>
>> Martin
>>
>>
>> 
>> From: Taylor, Karl E. 
>> Sent: 06 May 2019 16:34
>> To: Plummer, David (EC); Michaela Hegglin; Juckes, Martin (STFC,RAL,RALSP)
>> Cc: David Neubauer; sen...@meteo.fr; RIGOUDY Gaelle; Michael Schulz
>> Subject: Re: vt100
>>
>> Hi Martin,
>>
>> It appears to me that perhaps more important than the inconsistency
>> between standard_name and units, is the issue of whether or not to
>> remove an instantaneous zonal-mean or a local time mean (or perhaps
>> operate without removing any sort of mean).  Since the heat flux is
>> simply the temperture flux scaled by the specific heat of air at
>> constant pressure with a value of about 1000 J kg-1 K-1, users can
>> probably guess whether heat flux or temperature flux is actually being
>> reported and correct for it.  Users will not generally be able to guess
>> whether deviations from some mean or full quantities are used in
>> calculated the products.
>>
>> Since vt100 is used for a fairly specific "aerochem" diagnostic, I think
>> they should decide what they *really* want (and need for their
>> analysis).  Then I think we should make an exception to our rule
>> (because the science apparently demands it) and modify the data request
>> to reflect this.  If there is any way we can do this without changing
>> the current standard_name for vt100, that would certainly be best
>> because then all data would be searched for using the same standard
>> name.  The units would be inconsistent for some already written data
>> sets, but errata could be recorded by es-docs for those models
>> indicating the error in units.
>>
>> best regards,
>> Karl
>>
>>
>> On 5/4/19 3:28 PM, Plummer, David (EC) wrote:
>>> Hi Michaela
>>>I'll admit to being a bit out of my depth on stratopheric dynamics, but 
>>> from a practical standpoint looking at our diagnostic codes that were 
>>> developed by Charles McLandress we calculate the eddy meridional heat flux 
>>> as the product of the instantaneous deviations around the instantaneous 
>>> zonal average of the meridional velocity and temperature. The end product 
>>> is the zonal and monthly average of this product. This calculation does 
>>> agree with the description of V'T' in the literature where the primes are 
>>> used to denote deviations around the zonal mean.
>>>   Note that the MIP table for CCMI, which derives from the CCMVal data 
>>> request, has the following comment:Zonally averaged meridional heat 
>>> flux at 100 hPa as monthly means derived from daily (or higher frequency) 
>>> fields
>>>It is really important that the sampling be daily or better because you 
>>> want to capture the meridional advection of temperature by transient eddies.
>>>It is one of the terms in the Transformed Eulerian Mean (TEM) 
>>> calculation of the stratospheric residual circulation and the value at 100 
>>> hPa is usually seen as a proxy for the total amount of planetary wave drag 
>>> entering the stratosphere. Chapter 4 of the CCMVal report, Stratospheric 
>>> Dynamics, used the term 'eddy meridional heat flux' and referenced a paper 
>>> by Newman et al. (2001) where this term is referred to similarly. I have 
>>

[CF-metadata] Standard name of isobaric zonal mean eddy meridional temperature advection

[Martin Juckes - UKRI STFC]

Hello All,


For AerChemMIP we need a new standard name for a quantity which is the isobaric 
zonal mean of the eddy meridional temperature advection. That is, the mean wrt. 
longitude of the product of v' and T', where v' and T' are the eddy meridional 
velocity and air temperature respectively and "eddy" denotes the departure from 
the isobaric zonal mean. The units should be "K m s-1"


This is related to two existing terms:

  1.  northward_heat_flux_in_air_due_to_eddy_advection  [W m-2]
  2.  product_of_northward_wind_and_air_temperature  [K m s-1]

The first of these involves the eddy advection, but includes a factor of 
density and the specific heat constant. Since density is spatially varying, (1) 
can not be directly converted to the term we want, though there is an 
approximate relationship.

The second specifies the product, but without reference to the eddies.

The term "eddy_advection" occurs in 38 existing terms, always in the form 
"_due_to_[...]eddy_advection", describing the part of some process which 
can be attributed to some kind of eddy advection.  In this case we want a term 
for the eddy advection itself.

In some preliminary discussion we have the following ideas:

(1) 
northward_heat_flux_expressed_as_temperature_flux_in_air_due_to_eddy_advection 
-- staying close to the existing heat flux term;
(2) northward_temperature_flux_in_air_due_to_eddy_advection -- more descriptive
(3) Karl has suggested terms based on "product_of_...", to avoid the use of 
"temperature flux", because the notion of "flux" sits uncomfortably with a 
non-conservative quantity like temperature.

In reviewing the use of "eddy_advection" in existing terms, I can see that the 
nature of the eddy advection is clearly defined in 27 of them, and the heat 
flux term above is the only one for which the user is left to guess. The 
standard interpretation would be as a departure from the isobaric zonal mean, 
but that is not spelled out in the standard name.

Combining some of the ideas from Karl and Michaela (suggestion 2 above), I 
think we could use:


  *   northward_isobaric_zonal_mean_eddy_advection_of_air_temperature

This differs from Karl's suggestions in using "eddy_advection" rather than 
trying to adapt "product_of" to deal with this use case.

The phrase "isobaric_zonal_mean_eddy_advection" would be defined as the zonal 
mean advection by eddies defined as the departure from the instantaneous 
isobaric zonal mean of the velocity and the advected quantity.

I'm submitting this on behalf of the group, so please consider comments by Karl 
and Michaela below. The discussion is still quite open, but I think it is 
better to engage with the CF list at this stage (the definition of the term we 
want to represent is clear).

regards,
Martin

From: Taylor, Karl E. 
Sent: 07 May 2019 23:15
To: Michaela Hegglin; Juckes, Martin (STFC,RAL,RALSP)
Cc: Plummer, David (EC); David Neubauer; sen...@meteo.fr; RIGOUDY Gaelle; 
Michael Schulz
Subject: Re: vt100

I just noticed that there is a standard_name
"product_of_northward_wind_and_air_temperature".  Perhaps this could be
modified to something indicating we're only considering the "eddy"
component, e.g.,
"eddy_component_of_product_of_northward_wind_and_air_temperature" or
"product_of_northward_wind_and_air_temperature_eddy_components" or
eddy_associated_product_of_northward_wind_and_air_temperature".
best,
Karl

On 5/7/19 2:23 AM, Michaela Hegglin wrote:
> Hi Martin, Karl,
>
> I got some more input from the DynVarMIP people on this too and Martin has 
> analysed this correctly.
>
> It seems that v’T’ * c_p * \rho would give us the correct units in [W/m^2].  
> The c_p factor is trivial, but the density isn't. Since it is requested on a 
> specific pressure level, it would depend only on the temperature at 100 hPa: 
> \rho = 10^4 Pa/RT.  This does add some nonlinearity.  To do it properly, 
> you’d need the account for variations in \rho (T) in time and space.
>
> Hence, would it be possible to keep the calculation as it is done by most 
> researchers as v’T’ and rename the variable to
>
> northward_temperature_flux_in_air_due_to_eddy_advection with units of [m K 
> s-1].
>
> Also, by “eddy_advection”,  people do mean deviations from the instantaneous 
> zonal mean.
>
> If it doesn’t sound like changing the name is a good idea, we could simply 
> change the units to [K m s-1], and explain that v’T’ was intended?
>
> This is what people expect to deliver for this variable as Gaelle’s case 
> shows too.
>
>
> Michaela
>
>
>
>
>> On 7 May 2019, at 09:30, Martin Juckes - UKRI STFC 
>>  wrote:
>>
>> Hi Karl,
>>
>>
>> It would need a new standard name ..

Re: [CF-metadata] Missing data bins in histograms

[Martin Juckes - UKRI STFC]

Dear Jonathan, Jim,



I’m sorry to have dropped this conversation after starting it three years ago. 
We ended up not fixing the problem for CMIP6, but I think it is worth taking 
another look.



Coming back to it again, I think that a variation on Jim’s suggestion could 
work: rather than using flags it should be possible to use a coordinate 
variable, as is done for some CMIP variables that have region names along one 
axis. The NetCDF  dimension would be an index, and the array of values defining 
the bins would be an auxiliary coordinate which, I believe, is not subject to 
the rules on monotonicity and missing values which apply to NetCDF dimensions. 
There may be a need for some clarifications, but I think this approach would be 
much closer to the current convention that any change in the specification for 
non-auxiliary coordinate variables.


We have a specific use case in CMIP6 for which the bins are height bins (height 
of detected cloud), with one bin reserved for "retrieval error".


This might not need a change in the convention rules, but it would help, I 
think, to at least add an example and a standard name for the coordinate 
variable. For example:


float data(time,lat,lon,zindex);

  data: standard_name =   
"histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid";

  data: coordinates="zbins";

float zbins(zindex);

  zbins: long_name="Height ranges (with bin for missing data at first element)";

  zbins:missing_value= -.;

  zbins: units="m";

  zbins: bounds="zbin_bnds";

  zbins: standard_name = "";

float zbin_bnds(zindex,2);

  zbin_bnds:missing_value= -.;

float lat(lat);

float lon(lon);


data:

  zbins = -., 25., 100., ;

  zbin_bnds = -.,-., 0., 50., 50., 150., ...


The use of missing_value in the bounds variable appears to conflict with 
conformance rules, but I'm not sure if this is really banned by the convention 
in this context.


Using missing_value in this way appears to be acceptable to the convention, but 
I think it conflicts with the spirit of the convention: it is not indicating 
that a value of "zbins" is missing, but indicating that this index of the array 
relates to a count of missing values. For this reason I have omitted _FillValue.


The "zbins" auxiliary coordinate here is a height-like variable, but I don't 
think we can use a standard name "height": is it worth adding a standard name 
"height_bins" defined to be "Height ranges, as used, for example in a histogram 
or frequency distribution. A variable with this standard name may include a 
special bin for the count or frequency of missing data. This should be 
indicated by setting the value of that bin and its bounds to equal the 
missing_value of the variable. If there is no missing value bin, it is 
recommended that the term 'height' be used instead."


regards,

Martin


CF-metadata] Missing data bins in histograms

Jonathan Gregoryj.m.gregory at reading.ac.uk 

Thu Oct 13 03:42:47 MDT 2016

  *   Previous message (by thread): [CF-metadata] Missing data bins in 
histograms 
  *   Next message (by thread): [CF-metadata] Usage of histogram_of_X_over_Z 

  *   Messages sorted by: [ date 
] [ 
thread 
] [ 
subject 
] [ 
author 
]



Dear Jim



In Appendix A it does not say that the flag attributes are allowed for

coordinate variables - it has just "D" in the "Use" column. This is not an

argument why they shouldn't be if there is a need, but they weren't introduced

with that in mind. The use which you suggested for Martin's case is a good

idea, but I think it would need a change to the convention.



Best wishes



Jonathan



- Forwarded message from Jim Biard http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> -



> Date: Wed, 12 Oct 2016 14:58:11 -0400

> From: Jim Biard  cicsnc.org>

> To: cf-metadata at 
> cgd.ucar.edu

> Subject: Re: [CF-metadata] Missing data bins in histograms

> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)

>  Gecko/20100101 Thunderbird/45.4.0

>

> Jonathan,

>

> Missing/fill values are not allowed, but I don't see any language

> prohibiting flags. I'd appreciate it if you could expand on your

> thoughts about why they aren't allowed.

>

> Grace 

Re: [CF-metadata] Some standard name updates to improve consistency.

[Martin Juckes - UKRI STFC]

stratiform_cloud_snow_particles

One could argue about the reference to ice, rain and snow "particles" which is 
probably not the most obvious terminology, but I suspect we chose to treat the 
names this way for consistency with the liquid water names. Unless anyone 
objects I will also add these aliases in the May update.

Interestingly, there is one cloud effective radius name that already says 
"particles", effective_radius_of_cloud_condensed_water_particles_at_cloud_top, 
so that will no longer be the odd one out!

As you say, we already use "particles" in the vast majority of aerosol names. I 
can find only four that use the singular:
aerodynamic_particle_diameter
ambient_aerosol_particle_diameter
electrical_mobility_particle_diameter
relative_humidity_for_aerosol_particle_size_selection

It is natural to use "particle" if the names are written as above, but I think 
it can also be argued that the diameter names should be constructed following a 
similar pattern to the effective radius names, i.e. diameter_of_particles 
rather than "particle_diameter". If we take this approach, the names would 
become:
aerodynamic_diameter_of_particles
diameter_of_ambient_aerosol_particles
electrical_mobility_diameter_of_aerosol_particles
relative_humidity_for_size_selection_of_aerosol_particles.
(This also makes clear that the electrical mobility name refers to aerosol 
particles).

If we make these changes, then I think we shouldn't alter the radiative effect 
names to say "particle".

I'm putting this forward as a possible alternative, but would also be fine with 
your approach to the aerosol names. I'd be interested to know what you think.

Best wishes,
Alison

---
Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: 
mailto: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 Martin 
Juckes - UKRI STFC
Sent: 24 April 2019 13:42
To: CF-metadata (mailto:cf-metadata@cgd.ucar.edu) 
<mailto:cf-metadata@cgd.ucar.edu>
Subject: [CF-metadata] Some standard name updates to improve consistency.

Hello All,


The standard name table has a high degree of internal consistency across 
thousands of variables, but there are a few anomalies. I'd like to suggest a 
few changes below.  These are minor issues,


 1. Change "aerosol" to "aerosol_particles".

The overwhelming majority of aerosol terms refer to "aerosol_particles". There 
are two anomalies:


  *   
tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur_due_to_wet_deposition
  *   mercury_dry_aerosol

Should these be changed to "aerosol_particles"?

2. Primary production vs. primary productivity

There are 6 terms for 
net_primary_productivity_of_biomass_expressed_as_carbon..., and one for 
net_primary_production_of_biomass_expressed_as_carbon_per_unit_volume_in_sea_water.
 In addition, there are 6 terms using primary_production in the construction 
"due_to_net_primary_production".

Production and productivity are often used interchangeably, but some people 
draw a distinction. E.g. using "productivity" for a rate and "production" for 
an amount. The usage in the standard names could be interpreted as using 
"primary_production" in oceanic contexts and "primary_productivity" in land 
contexts, but net_primary_productivity_of_biomass_expressed_as_carbon is not 
explicitly defined as applying only to land. Should it be?

Can we either change these terms to consistently use "productivity" (or 
"production"), or, if that is not appropriate, provide some explanation of the 
use of two different terms for the same quantity?

3. aerodynamic_resistance

The definition of this term implies that it refers to the aerodynamic 
resistance of the boundary layer, rather than the more general concept of 
aerodynamic resistance as defined, for example, by AMS: 
http://glossary.ametsoc.org/wiki/Aerodynamic_resistance .

If the narrower term is intended, perhaps the name should be changed to 
aerodynamic_resistance_of_planetary_boundary_layer, so that it is clear that 
this is a boundary layer property.

4. Litter and Soil

To mean the combination of litter and soil, we have one use of 
"soil_and_litter", one of "litter_and_soil". There are multiple uses of 
"vegetation_litter_and_soil", so we can take this as the preferred order.

Can we change 
carbon_mass_flux_into_soil_and_litter_due_to_anthropogenic_land_use_or_land_cover_change
 to 
carbon_mass_flux_into_litter_and_soil_due_to_anthropogenic_land_use_or_land_cover_change
 for consi

[CF-metadata] Standard name issues: spelling typo and invalid name referenced in conventions document

[Martin Juckes - UKRI STFC]

Dear Alison, CF list,


I've come across a couple of CF Standard Name issues:


(1) ocean_double_sigma_coordinate is referred to in the conventions document 
(1.7 and 1.8) as a standard_name, but it is not in the standard name list. I 
think the easiest approach is to add the name to the list.


(2) The term 
tendency_of_atmosphere_number_content_of_aerosol_particles_due_to_turbulent_depostion
  has an "i" missing from "deposition".


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Some standard name updates to improve consistency.

[Martin Juckes - UKRI STFC]

one out!

As you say, we already use "particles" in the vast majority of aerosol names. I 
can find only four that use the singular:
aerodynamic_particle_diameter
ambient_aerosol_particle_diameter
electrical_mobility_particle_diameter
relative_humidity_for_aerosol_particle_size_selection

It is natural to use "particle" if the names are written as above, but I think 
it can also be argued that the diameter names should be constructed following a 
similar pattern to the effective radius names, i.e. diameter_of_particles 
rather than "particle_diameter". If we take this approach, the names would 
become:
aerodynamic_diameter_of_particles
diameter_of_ambient_aerosol_particles
electrical_mobility_diameter_of_aerosol_particles
relative_humidity_for_size_selection_of_aerosol_particles.
(This also makes clear that the electrical mobility name refers to aerosol 
particles).

If we make these changes, then I think we shouldn't alter the radiative effect 
names to say "particle".

I'm putting this forward as a possible alternative, but would also be fine with 
your approach to the aerosol names. I'd be interested to know what you think.

Best wishes,
Alison

-------
Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Martin Juckes 
- UKRI STFC
Sent: 24 April 2019 13:42
To: CF-metadata (cf-metadata@cgd.ucar.edu) 
Subject: [CF-metadata] Some standard name updates to improve consistency.

Hello All,


The standard name table has a high degree of internal consistency across 
thousands of variables, but there are a few anomalies. I'd like to suggest a 
few changes below.  These are minor issues,


 1. Change "aerosol" to "aerosol_particles".

The overwhelming majority of aerosol terms refer to "aerosol_particles". There 
are two anomalies:


  *   
tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur_due_to_wet_deposition
  *   mercury_dry_aerosol

Should these be changed to "aerosol_particles"?

2. Primary production vs. primary productivity

There are 6 terms for 
net_primary_productivity_of_biomass_expressed_as_carbon..., and one for 
net_primary_production_of_biomass_expressed_as_carbon_per_unit_volume_in_sea_water.
 In addition, there are 6 terms using primary_production in the construction 
"due_to_net_primary_production".

Production and productivity are often used interchangeably, but some people 
draw a distinction. E.g. using "productivity" for a rate and "production" for 
an amount. The usage in the standard names could be interpreted as using 
"primary_production" in oceanic contexts and "primary_productivity" in land 
contexts, but net_primary_productivity_of_biomass_expressed_as_carbon is not 
explicitly defined as applying only to land. Should it be?

Can we either change these terms to consistently use "productivity" (or 
"production"), or, if that is not appropriate, provide some explanation of the 
use of two different terms for the same quantity?

3. aerodynamic_resistance

The definition of this term implies that it refers to the aerodynamic 
resistance of the boundary layer, rather than the more general concept of 
aerodynamic resistance as defined, for example, by AMS: 
http://glossary.ametsoc.org/wiki/Aerodynamic_resistance .

If the narrower term is intended, perhaps the name should be changed to 
aerodynamic_resistance_of_planetary_boundary_layer, so that it is clear that 
this is a boundary layer property.

4. Litter and Soil

To mean the combination of litter and soil, we have one use of 
"soil_and_litter", one of "litter_and_soil". There are multiple uses of 
"vegetation_litter_and_soil", so we can take this as the preferred order.

Can we change 
carbon_mass_flux_into_soil_and_litter_due_to_anthropogenic_land_use_or_land_cover_change
 to 
carbon_mass_flux_into_litter_and_soil_due_to_anthropogenic_land_use_or_land_cover_change
 for consistency?


5. Products


There are 7 terms which use the old name "omega", which is now aliassed to 
"lagrangian_tendency_of_air_pressure".  Two of these are redundant, because 
they are of the form "product_of_B_and_A" for terms already covered by 
"product_of_A_and_B".

 1. product_of_specific_humidity_and_omega
 2. product_of_omega_and_specific_humidity [redundant]  3. 
product_of_eastward_wind_and_omega
 4. product_of_northward_wind_and_omega
 5. product_of_air_temperature_and_omega
 6. product_of_omega_and_air_temperature [redundant]  7. 
product_of_geopotenti

Re: [CF-metadata] Some standard name updates to improve consistency.

[Martin Juckes - UKRI STFC]

Hi Karl,


OK .. it looks to me as though there is some blurring between, on the one hand, 
the idea of an attenuation rate (the rate at which a flux we are measuring is 
attenuated) and, on the other hand, an attenuation coefficient (a property of a 
medium defined in terms of a hypothetical or reference flux). However, if that 
doesn't worry the people using the term, we can leave it as it is.


I've found one paper on the subject which indicates that the spectrally 
resolved attenuation coefficient is, to a large extent, independent of sea 
water properties and only depends on the spectral frequency. The spectrally 
averaged attenuation coefficient varies with solar zenith angle and depth 
because these affect the spectrum and hence the weighting of the spectral 
average (Lee et al, doi:10.1029/2004JC002780).


regards,

Martin


From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 24 April 2019 16:37
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Some standard name updates to improve consistency.

Hi Martin,

Regarding item 7, I'm guessing you're right that the attenuation is
wavelength specific and the downwelling shortwave has a different
spectrum that the upwelling.  So I wouldn't remove "downwelling" without
some guidance from experts.

best regards,
Karl

On 4/24/19 5:41 AM, Martin Juckes - UKRI STFC wrote:
> Hello All,
>
>
> The standard name table has a high degree of internal consistency across 
> thousands of variables, but there are a few anomalies. I'd like to suggest a 
> few changes below.  These are minor issues,
>
>
>   1. Change "aerosol" to "aerosol_particles".
>
> The overwhelming majority of aerosol terms refer to "aerosol_particles". 
> There are two anomalies:
>
>
>*   
> tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur_due_to_wet_deposition
>*   mercury_dry_aerosol
>
> Should these be changed to "aerosol_particles"?
>
> 2. Primary production vs. primary productivity
>
> There are 6 terms for 
> net_primary_productivity_of_biomass_expressed_as_carbon..., and one for 
> net_primary_production_of_biomass_expressed_as_carbon_per_unit_volume_in_sea_water.
>  In addition, there are 6 terms using primary_production in the construction 
> "due_to_net_primary_production".
>
> Production and productivity are often used interchangeably, but some people 
> draw a distinction. E.g. using "productivity" for a rate and "production" for 
> an amount. The usage in the standard names could be interpreted as using 
> "primary_production" in oceanic contexts and "primary_productivity" in land 
> contexts, but net_primary_productivity_of_biomass_expressed_as_carbon is not 
> explicitly defined as applying only to land. Should it be?
>
> Can we either change these terms to consistently use "productivity" (or 
> "production"), or, if that is not appropriate, provide some explanation of 
> the use of two different terms for the same quantity?
>
> 3. aerodynamic_resistance
>
> The definition of this term implies that it refers to the aerodynamic 
> resistance of the boundary layer, rather than the more general concept of 
> aerodynamic resistance as defined, for example, by AMS: 
> http://glossary.ametsoc.org/wiki/Aerodynamic_resistance .
>
> If the narrower term is intended, perhaps the name should be changed to 
> aerodynamic_resistance_of_planetary_boundary_layer, so that it is clear that 
> this is a boundary layer property.
>
> 4. Litter and Soil
>
> To mean the combination of litter and soil, we have one use of 
> "soil_and_litter", one of "litter_and_soil". There are multiple uses of 
> "vegetation_litter_and_soil", so we can take this as the preferred order.
>
> Can we change 
> carbon_mass_flux_into_soil_and_litter_due_to_anthropogenic_land_use_or_land_cover_change
>  to 
> carbon_mass_flux_into_litter_and_soil_due_to_anthropogenic_land_use_or_land_cover_change
>  for consistency?
>
>
> 5. Products
>
>
> There are 7 terms which use the old name "omega", which is now aliassed to 
> "lagrangian_tendency_of_air_pressure".  Two of these are redundant, because 
> they are of the form "product_of_B_and_A" for terms already covered by 
> "product_of_A_and_B".
>
>   1. product_of_specific_humidity_and_omega
>   2. product_of_omega_and_specific_humidity [redundant]
>   3. product_of_eastward_wind_and_omega
>   4. product_of_northward_wind_and_omega
>   5. product_of_air_temperature_and_omega
>   6. product_of_omega_and_air_temperature [redundant]
>   7. product_of_geopotential_height_and_omega
>
>
&g

Re: [CF-metadata] Some standard name updates to improve consistency.

[Martin Juckes - UKRI STFC]

Dear Roy,


thanks ... I'd overlooked that specification of productivity in the 
descriptions.


I've looked at the units of course .. happy to take on board any other 
suggestions.


regards,

Martin


From: Lowry, Roy K. 
Sent: 24 April 2019 19:03:35
To: Juckes, Martin (STFC,RAL,RALSP); CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: Some standard name updates to improve consistency.

Dear Martin,

>From what I can see, the productivity Standard Name descriptions use the 
>phrase '"Productivity" means production per unit area'. Looking at the 
>canonical units productivity is moles_or_mass/m2/s, whereas production is 
>moles_or_mass/m3/s. This means that productivity is in fact the depth integral 
>of production and not the rate of a state variable.

I would suggest that before doing any 'tidying up' that the canonical units are 
checked.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Martin Juckes 
- UKRI STFC 
Sent: 24 April 2019 13:41
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Some standard name updates to improve consistency.

Hello All,


The standard name table has a high degree of internal consistency across 
thousands of variables, but there are a few anomalies. I'd like to suggest a 
few changes below.  These are minor issues,


 1. Change "aerosol" to "aerosol_particles".

The overwhelming majority of aerosol terms refer to "aerosol_particles". There 
are two anomalies:


  *   
tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur_due_to_wet_deposition
  *   mercury_dry_aerosol

Should these be changed to "aerosol_particles"?

2. Primary production vs. primary productivity

There are 6 terms for 
net_primary_productivity_of_biomass_expressed_as_carbon..., and one for 
net_primary_production_of_biomass_expressed_as_carbon_per_unit_volume_in_sea_water.
 In addition, there are 6 terms using primary_production in the construction 
"due_to_net_primary_production".

Production and productivity are often used interchangeably, but some people 
draw a distinction. E.g. using "productivity" for a rate and "production" for 
an amount. The usage in the standard names could be interpreted as using 
"primary_production" in oceanic contexts and "primary_productivity" in land 
contexts, but net_primary_productivity_of_biomass_expressed_as_carbon is not 
explicitly defined as applying only to land. Should it be?

Can we either change these terms to consistently use "productivity" (or 
"production"), or, if that is not appropriate, provide some explanation of the 
use of two different terms for the same quantity?

3. aerodynamic_resistance

The definition of this term implies that it refers to the aerodynamic 
resistance of the boundary layer, rather than the more general concept of 
aerodynamic resistance as defined, for example, by AMS: 
http://glossary.ametsoc.org/wiki/Aerodynamic_resistance .

If the narrower term is intended, perhaps the name should be changed to 
aerodynamic_resistance_of_planetary_boundary_layer, so that it is clear that 
this is a boundary layer property.

4. Litter and Soil

To mean the combination of litter and soil, we have one use of 
"soil_and_litter", one of "litter_and_soil". There are multiple uses of 
"vegetation_litter_and_soil", so we can take this as the preferred order.

Can we change 
carbon_mass_flux_into_soil_and_litter_due_to_anthropogenic_land_use_or_land_cover_change
 to 
carbon_mass_flux_into_litter_and_soil_due_to_anthropogenic_land_use_or_land_cover_change
 for consistency?


5. Products


There are 7 terms which use the old name "omega", which is now aliassed to 
"lagrangian_tendency_of_air_pressure".  Two of these are redundant, because 
they are of the form "product_of_B_and_A" for terms already covered by 
"product_of_A_and_B".

 1. product_of_specific_humidity_and_omega
 2. product_of_omega_and_specific_humidity [redundant]
 3. product_of_eastward_wind_and_omega
 4. product_of_northward_wind_and_omega
 5. product_of_air_temperature_and_omega
 6. product_of_omega_and_air_temperature [redundant]
 7. product_of_geopotential_height_and_omega


Can we remove the two redundant terms, and replace "omega" with 
"lagrangian_tendency_of_air_pressure"?


6. Use of "net_downward" in aerosol indirect radiative effect terms


There are 5 aerosol direct radiative effect terms. These are analogous to cloud 
radiative effect terms (3)  and radiative forcing terms (12). For all the 
radiative forcing terms and the cloud radiative effect terms, the sign 
convention is assumed to be that positive forcing/radiative effe

[CF-metadata] Some standard name updates to improve consistency.

[Martin Juckes - UKRI STFC]

Hello All,


The standard name table has a high degree of internal consistency across 
thousands of variables, but there are a few anomalies. I'd like to suggest a 
few changes below.  These are minor issues,


 1. Change "aerosol" to "aerosol_particles".

The overwhelming majority of aerosol terms refer to "aerosol_particles". There 
are two anomalies:


  *   
tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur_due_to_wet_deposition
  *   mercury_dry_aerosol

Should these be changed to "aerosol_particles"?

2. Primary production vs. primary productivity

There are 6 terms for 
net_primary_productivity_of_biomass_expressed_as_carbon..., and one for 
net_primary_production_of_biomass_expressed_as_carbon_per_unit_volume_in_sea_water.
 In addition, there are 6 terms using primary_production in the construction 
"due_to_net_primary_production".

Production and productivity are often used interchangeably, but some people 
draw a distinction. E.g. using "productivity" for a rate and "production" for 
an amount. The usage in the standard names could be interpreted as using 
"primary_production" in oceanic contexts and "primary_productivity" in land 
contexts, but net_primary_productivity_of_biomass_expressed_as_carbon is not 
explicitly defined as applying only to land. Should it be?

Can we either change these terms to consistently use "productivity" (or 
"production"), or, if that is not appropriate, provide some explanation of the 
use of two different terms for the same quantity?

3. aerodynamic_resistance

The definition of this term implies that it refers to the aerodynamic 
resistance of the boundary layer, rather than the more general concept of 
aerodynamic resistance as defined, for example, by AMS: 
http://glossary.ametsoc.org/wiki/Aerodynamic_resistance .

If the narrower term is intended, perhaps the name should be changed to 
aerodynamic_resistance_of_planetary_boundary_layer, so that it is clear that 
this is a boundary layer property.

4. Litter and Soil

To mean the combination of litter and soil, we have one use of 
"soil_and_litter", one of "litter_and_soil". There are multiple uses of 
"vegetation_litter_and_soil", so we can take this as the preferred order.

Can we change 
carbon_mass_flux_into_soil_and_litter_due_to_anthropogenic_land_use_or_land_cover_change
 to 
carbon_mass_flux_into_litter_and_soil_due_to_anthropogenic_land_use_or_land_cover_change
 for consistency?


5. Products


There are 7 terms which use the old name "omega", which is now aliassed to 
"lagrangian_tendency_of_air_pressure".  Two of these are redundant, because 
they are of the form "product_of_B_and_A" for terms already covered by 
"product_of_A_and_B".

 1. product_of_specific_humidity_and_omega
 2. product_of_omega_and_specific_humidity [redundant]
 3. product_of_eastward_wind_and_omega
 4. product_of_northward_wind_and_omega
 5. product_of_air_temperature_and_omega
 6. product_of_omega_and_air_temperature [redundant]
 7. product_of_geopotential_height_and_omega


Can we remove the two redundant terms, and replace "omega" with 
"lagrangian_tendency_of_air_pressure"?


6. Use of "net_downward" in aerosol indirect radiative effect terms


There are 5 aerosol direct radiative effect terms. These are analogous to cloud 
radiative effect terms (3)  and radiative forcing terms (12). For all the 
radiative forcing terms and the cloud radiative effect terms, the sign 
convention is assumed to be that positive forcing/radiative effect is 
equivalent to a downward radiative flux.  This is also true for the TOA direct 
radiative effect term. For 4 terms describing the aerosol direct radiative 
effect at the surface, there is an additional inclusion of "net_downward" in 
the term. This looks redundant to me, and I think it should be removed for 
consistency with other radiative effect and forcing terms.


* 
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect

* 
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky

* 
surface_net_downward_shortwave_dust_ambient_aerosol_particles_direct_radiative_effect

* 
surface_net_downward_shortwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky


7. Use of "downwelling" in attenuation coefficients

Attenuation of radiation is a measure of the reduction of strength of a 
radiation wave passing through a medium. It does not depend on the direction of 
travel of the radiation. One term includes redundant directional information:

  * volume_attenuation_coefficient_of_downwelling_radiative_flux_in_sea_water

This term is intended have some relevance to downwelling fluxes in sea water. 
Possibly it is intended to be evaluated at frequencies representative of the 
downwelling radiative flux.

 Can we remove "downwelling" from this term and/or clarify any assumptions 
about spectral range?


8. Specification of air vs. ocean

Scattering terms all specify 

Re: [CF-metadata] proposed migration of these discussions to GitHub

[Martin Juckes - UKRI STFC]

Hello Jonathan,


I also approve of this.


Perhaps this would be an opportunity to update 
http://cfconventions.org/discussion.html which appears out of date. Perhaps 
that page could be retired and replaced with a github page listing the relevant 
links, including 
https://github.com/cf-convention/cf-conventions/blob/master/CONTRIBUTING.md for 
conventions changes and a new page for standard names.


regards,

Martin


From: CF-metadata  on behalf of Signell, 
Richard 
Sent: 25 March 2019 15:12:57
To: Daniel Lee
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] proposed migration of these discussions to GitHub

Jonathan & List,
I strongly agree with this new approach as well.   Technical
discussions in email are very hard to track, and I believe many people
who might be contributors don't engage for this reason.   I think
discussion in Github issues will accelerate our progress.

Thanks for doing this,
Rich

On Mon, Mar 25, 2019 at 10:48 AM Daniel Lee  wrote:
>
> Dear Jonathan, List,
>
> I think these changes will be an improvement in how we handle evolving CF. 
> Your assessment is sound in my eyes and I think these changes will bring 
> substantial benefits. Thanks for the hard work and attention to detail.
>
> Cheers,
> Daniel
>
> > -Original Message-
> > From: CF-metadata  On Behalf Of
> > Jonathan Gregory
> > Sent: Friday 22 March 2019 17:58
> > To: cf-metadata@cgd.ucar.edu
> > Subject: [CF-metadata] proposed migration of these discussions to GitHub
> >
> > Dear all
> >
> > As you know, CF currently uses this email list for discussion of standard 
> > name
> > proposals and all other matters except for proposals to change the
> > conventions.
> >
> > For the latter, we have been using trac for years, but have recently
> > completed migration of that function to GitHub. The source of the CF
> > conventions document is now in GitHub and version 1.7 was generated from
> > it. In future, proposed conventions changes will be discussed as GitHub
> > issues on the conventions repository, and the changes in wording will be
> > finalised in pull requests. This is convenient because it provides 
> > continuity
> > from the discussion to the modified document. We are due to prepare and
> > release version 1.8, freeze trac and publish guidelines for using GitHub in
> > future for conventions changes.
> >
> > One of the reasons this has not yet been done is that it's important to keep
> > everyone informed of conventions changes. For a while, postings to the
> > GitHub conventions repository were sent to the subscribers to this email 
> > list,
> > but as you remember there were complaints about the amount of traffic,
> > and some confusions were caused by people replying to GitHub by email, so
> > the email feed was switched off while there was further discussion on the CF
> > committee of how to proceed.
> >
> > Now we would like to present a new proposal, as follows:
> >
> > * To change to using GitHub for standard name proposals and all other
> > matters, as issues in a different repository from the conventions (probably
> > called "discuss"). If we make this change, anyone who wishes to make a new
> > standard name proposal or start a discussion thread about something else
> > will need a GitHub username, and will log on to GitHub and post it there as 
> > a
> > new GitHub issue. This is not difficult (see below). It does not involve 
> > any of
> > the complexity of git for making updates to a repository as this will be a 
> > place
> > solely to hold discussions and keep an archive of them.
> >
> > * To make sure that all existing subscribers to this list are kept in touch,
> > postings to the GitHub issues in the discuss and conventions repositories 
> > will
> > be distributed via email, initially to all subscribers to this email list.
> > Their subject lines will begin with [cf-metadata/discuss] and [cf-
> > metadata/conventions]. However, it will no longer be possible to reply to
> > them on this email list. The archives will be kept and also copied to 
> > GitHub. To
> > comment on a standard name proposal or other discussion, there will be two
> > options:
> >
> > * Either you can log onto GitHub and add to the issue in the discuss
> > repository,
> >
> > * Or you can *unsubscribe* from the broadcast emails (instructions will be
> > given for that), and instead *watch* the GitHub discuss repository. That
> > means you will receive the updates to issues by email from GitHub, rather
> > than via an email list, and you can then reply to GitHub by email. Your 
> > reply is
> > magically posted on GitHub. That facility means that you can carry out a
> > discussion of an issue entirely by email, once it's started, not much
> > differently from an email list.
> >
> > We do not wish to lose members of the CF community who are subscribed to
> > this list and remain interested in CF. The main reason for my writing this 
> > now
> > is to ask whether there are 

[CF-metadata] Optional (?) coordinates on aerosol optical thicknesses

[Martin Juckes - UKRI STFC]

Dear Alison,


The two standard names:

atmosphere_optical_thickness_due_to_ambient_aerosol_particles and

atmosphere_absorption_optical_thickness_due_to_ambient_aerosol_particles

Include the following in there descriptions:

'To specify the relative humidity and temperature at which the quantity 
described by the standard name applies, provide scalar coordinate variables 
with standard names of "relative_humidity" and "air_temperature".'


I believe this should be interpreted as optional, is that correct? When they 
are used in CMIP6, the associated relative humidity and temperature will be 
provided in separate files, it would be awkward for everyone if they were 
required in the same file. Can we change "provide scalar ." to "scalar 
. may be provided."?


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Adding sensor_elevation_angle to standard_name

[Martin Juckes - UKRI STFC]

Hi Ken,


We don't need to have "zenith" in the table, but we do want to have a 
consistent meaning. There is a table (probably incomplete) of terms used in 
standard names here: 
http://cfconventions.org/Data/cf-standard-names/docs/guidelines.html#id2798851, 
it is probably worth adding "zenith" to this table.


It looks to me as though the definition in sensor_zenith_angle is a simple 
mistake. The term was added in 2013, and the initial proposal defines it as 
relative to the local vertical 
(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/005883.html). The 
subsequent email discussion makes it clear that it is intended to be consistent 
with platform_zenith_angle. Alison may be able to say more about this (I 
haven't reviewed the whole discussion thread).


To be on the safe side, can we define horizontal as "perpendicular to Earth's 
gravity", to eliminate the time varying lunar component which may not matter to 
your measurements, but is bound to worry somebody sooner or later.


regards,

Martin








From: Kehoe, Kenneth E. 
Sent: 19 March 2019 18:48
To: Juckes, Martin (STFC,RAL,RALSP); CF Metadata List
Subject: Re: Adding sensor_elevation_angle to standard_name

Hi Martin,

Yeah I went round and round with this trying to reuse the current definitions, 
but they were a little confusing to me. Using the statement "Local zenith is a 
line perpendicular to the Earth's surface at a given location." in 
sensor_zenith_angle (and platform_zenith_angle) does not work for me because I 
want zenith to be defined by direction of gravity not the Earth's surface.  The 
Earth's surface is often tilted. I think that needs to be updated according to 
my understanding of the term zenith. I assume there could be a use for angle 
between local surface of Earth, but I think that would be a different term than 
zenith. I think zenith_angle is currently OK. Is it worth defining zenith in 
the table for referencing by other standard_name's? I don't really know if that 
is how the standard_name table is designed to work.

I want the reference horizontal plane to be perpendicular to gravity, not the 
other definition where horizon is where the Earth surface and sky 
meet<https://www.merriam-webster.com/dictionary/horizon>. Is it worth creating 
a horizontal_plane standard name? I guess we could add something to allow a 
user to add "A comment attribute should be added to a data variable with this 
standard name to specify the reference direction." like sensor_azimuth_angle if 
they wanted to change it? But to be honest I don't understand this instruction 
in the sensor_azimuth_angle description statement and would probably never use 
it.

You may also need to update sensor_view_angle and sensor_zenith_angle from 
"line of sight from the sensor" to "line of sight of the sensor", but I don't 
want this proposal to get bogged down with changing the other standard name 
definitions. It may just be my interpretation and the existing definitions of 
sensor_zenith_angle and sensor_view_angle are correct.


Here is an updated definition:

proposed definition = sensor_elevation_angle is the angle measured in the 
vertical plane between the line of sight of the sensor and a horizontal plane 
perpendicular to local zenith. This angle is measured starting at zero from the 
horizontal plane directly in front of sensor. The angle is positive above the 
horizontal plane, and negative below the horizontal plane. Local zenith is 
directly overhead in the direction of gravity. A standard name also exists for 
sensor_view_angle and sensor_zenith_angle.

Ken



On 2019-3-19 03:56, Martin Juckes - UKRI STFC wrote:

Hello Ken,


this looks like a straight forward extension of existing names, but I'm puzzled 
by the definition of "zenith" in sensor_zenith_angle, where it is defined as 
"Local zenith is a line perpendicular to the Earth's surface at a given 
location." For the standard name "zenith_angle" the definition is different: 
"Zenith angle is the angle to the local vertical". The latter, with vertical 
defined by the direction of gravity, appears to be the standard usage: would 
you agree with this?


Is the reference to the Earth's surface in the definition of 
sensor_zenith_angle a mistake, which should be modified to bring it into line 
with zenith_angle, or is there a real need to have angles measured relative to 
the local plane of the Earth's surface?


For the sensor_elevation_angle, do you want a specific interpretation of 
"horizontal" (e.g. perpendicular to the direction of gravity), or is it 
acceptable to use this term with other interpretations of the reference 
horizontal plane?


regards,

Martin



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Kehoe, Kenneth E. <mailto:kke...@ou.edu>

Re: [CF-metadata] Adding sensor_elevation_angle to standard_name

[Martin Juckes - UKRI STFC]

Hello Ken,


this looks like a straight forward extension of existing names, but I'm puzzled 
by the definition of "zenith" in sensor_zenith_angle, where it is defined as 
"Local zenith is a line perpendicular to the Earth's surface at a given 
location." For the standard name "zenith_angle" the definition is different: 
"Zenith angle is the angle to the local vertical". The latter, with vertical 
defined by the direction of gravity, appears to be the standard usage: would 
you agree with this?


Is the reference to the Earth's surface in the definition of 
sensor_zenith_angle a mistake, which should be modified to bring it into line 
with zenith_angle, or is there a real need to have angles measured relative to 
the local plane of the Earth's surface?


For the sensor_elevation_angle, do you want a specific interpretation of 
"horizontal" (e.g. perpendicular to the direction of gravity), or is it 
acceptable to use this term with other interpretations of the reference 
horizontal plane?


regards,

Martin



From: CF-metadata  on behalf of Kehoe, 
Kenneth E. 
Sent: 19 March 2019 00:27
To: CF Metadata List
Subject: [CF-metadata] Adding sensor_elevation_angle to standard_name

I would like to add sensor_elevation_angle to complement the existing 
sensor_azimuth_angle in the standard_name table.

proposed standard_name = sensor_elevation_angle

proposed canonical units = degree

proposed definition = sensor_elevation_angle is the angle measured in the 
vertical plane between the line of sight of the sensor and a horizontal plane 
perpendicular to local zenith. This angle is measured starting from the 
horizontal plane directly in front of sensor. The angle is positive above the 
horizontal plane, and negative below the horizontal plane. Local zenith is 
directly overhead. A standard name also exists for sensor_view_angle and 
sensor_zenith_angle.

Thanks,

Ken


--
Kenneth E. Kehoe
  Research Associate - University of Oklahoma
  Cooperative Institute for Mesoscale Meteorological Studies
  ARM Climate Research Facility - Data Quality Office
  e-mail: kke...@ou.edu | Office: 303-497-4754
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] March standard name table update

[Martin Juckes - UKRI STFC]

Dear Alison,


thanks for fixing all those definitions .. keeping the foundations of the 
convention strong,


regards,

Martin


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 06 March 2019 13:46:32
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] March standard name table update

Dear All,

The standard name table has been updated. The current version is now Version 
64, dated 5 March 2019. The changes have also been published on the NERC 
Vocabulary Server. As mentioned last time, I have been making corrections to a 
list of typographical errors in standard name definitions that were reported by 
Martin Juckes - the processing of these is now complete. There is also a small 
number of new additions to the table - all changes are listed at the end of 
this message.

The next update is planned for 9th April.

Best wishes,
Alison

---

V64 standard name changes

1. New names

a. One new name proposed by Ranjini Swaminathan:
toa_outgoing_radiance_per_unit_wavelength_due_to_solar_induced_fluorescence 
(Canonical unit: W m-2 sr-1 m-1)

b. One new name proposed by Katherine Pugsley:
enrichment_of_14C_in_carbon_dioxide_in_air_expressed_as_uppercase_delta_14C 
(Canonical unit: 1e-3)

2. New aliases

One new alias has been introduced to correct a spelling mistake in the name: 
(methLY changed to methYL)

mole_fraction_of_methlyglyoxal_in_air -> mole_fraction_of_methylglyoxal_in_air

3. Modifications to definitions of existing names

Typographical errors (such as spelling mistakes, missing/extra white-space, 
inconsistent use of single and double quotes, etc) have been corrected in the 
definitions of the following standard names:
atmosphere_mass_content_of_brox_expressed_as_bromine
atmosphere_mass_content_of_clox_expressed_as_chlorine
atmosphere_mass_content_of_hydroxyl_radical
atmosphere_mass_content_of_inorganic_bromine
atmosphere_mass_content_of_inorganic_chlorine
atmosphere_mass_content_of_methyl_peroxy_radical
atmosphere_mass_content_of_nitrate_radical
atmosphere_mass_content_of_peroxy_radicals
atmosphere_mass_content_of_toluene
atmosphere_moles_of_brox_expressed_as_bromine
atmosphere_moles_of_clox_expressed_as_chlorine
atmosphere_moles_of_hydroperoxyl_radical
atmosphere_moles_of_hydroxyl_radical
atmosphere_moles_of_inorganic_bromine
atmosphere_moles_of_inorganic_chlorine
atmosphere_moles_of_methyl_peroxy_radical
atmosphere_moles_of_nitrate_radical
atmosphere_moles_of_toluene
atmosphere_updraft_convective_mass_flux
change_over_time_in_sea_water_practical_salinity
mass_concentration_of_brox_expressed_as_bromine_in_air
mass_concentration_of_clox_expressed_as_chlorine_in_air
mass_concentration_of_hydroperoxyl_radical_in_air
mass_concentration_of_hydroxyl_radical_in_air
mass_concentration_of_inorganic_bromine_in_air
mass_concentration_of_inorganic_chlorine_in_air
mass_concentration_of_methyl_peroxy_radical_in_air
mass_concentration_of_nitrate_radical_in_air
mass_concentration_of_peroxy_radicals_in_air
mass_concentration_of_toluene_in_air
mass_fraction_of_bromine_chloride_in_air
mass_fraction_of_bromine_monoxide_in_air
mass_fraction_of_bromine_nitrate_in_air
mass_fraction_of_brox_expressed_as_bromine_in_air
mass_fraction_of_butane_in_air
mass_fraction_of_carbon_dioxide_in_air
mass_fraction_of_carbon_monoxide_in_air
mass_fraction_of_carbon_tetrachloride_in_air
mass_fraction_of_cfc113_in_air
mass_fraction_of_cfc113a_in_air
mass_fraction_of_cfc114_in_air
mass_fraction_of_cfc115_in_air
mass_fraction_of_cfc11_in_air
mass_fraction_of_cfc12_in_air
mass_fraction_of_chlorine_dioxide_in_air
mass_fraction_of_chlorine_monoxide_in_air
mass_fraction_of_chlorine_nitrate_in_air
mass_fraction_of_dichlorine_peroxide_in_air
mass_fraction_of_dinitrogen_pentoxide_in_air
mass_fraction_of_ethane_in_air
mass_fraction_of_ethanol_in_air
mass_fraction_of_ethene_in_air
mass_fraction_of_ethyne_in_air
mass_fraction_of_formaldehyde_in_air
mass_fraction_of_formic_acid_in_air
mass_fraction_of_gaseous_divalent_mercury_in_air
mass_fraction_of_gaseous_elemental_mercury_in_air
mass_fraction_of_halon1202_in_air
mass_fraction_of_halon1211_in_air
mass_fraction_of_halon1301_in_air
mass_fraction_of_halon2402_in_air
mass_fraction_of_hcc140a_in_air
mass_fraction_of_hcfc141b_in_air
mass_fraction_of_hcfc142b_in_air
mass_fraction_of_hcfc22_in_air
mass_fraction_of_hexachlorobiphenyl_in_air
mass_fraction_of_hox_expressed_as_hydrogen_in_air
mass_fraction_of_hydrogen_bromide_in_air
mass_fraction_of_hydrogen_chloride_in_air
mass_fraction_of_hydrogen_cyanide_in_air
mass_fraction_of_hydrogen_peroxide_in_air
mass_fraction_of_hydroperoxyl_radical_in_air
mass_fraction_of_hydroxyl_radical_in_air
mass_fraction_of_hypobromous_acid_in_air
mass_fraction_of_hypochlorous_acid_in_air
mass_fraction_of_inorganic_bromine_in_air
mass_fraction_of_inorganic_chlorine_in_air
mass_fraction_of_isoprene_in_air
mass_fraction_of_limonene_in_air
mass_fraction_of_methane_in_air
mass_fraction_of_methanol_in_air

[CF-metadata] Clarifications on some radiation and carbon flux terms

[Martin Juckes - UKRI STFC]

Hello All,


I've been reviewing some of the flux terms used for CMIP6, and have a few 
questions:


(1) downward_heat_flux_at_ground_level_in_snow:

What does "at_ground_level" mean on an ice sheet? The description says 
"ground_level means the land surface (beneath the snow and surface water, if 
any)". If "ground_level" is beneath a km of ice, "ground_level_in_snow" does 
not really make sense, does it? Does it mean the heat flux at the lower 
boundary of the snow pack into the ice or solid earth? The corresponding CMIP6 
variable, hfdsnb, is intended to have this meaning.


(2) surface_snow_and_ice_melt_heat_flux [W m-2]

Is this a flux into the atmosphere, or a flux into the column of snow and ice? 
The intention for the CMIP6 variable hfmlt is a little unclear.


(3) surface_net_downward_mass_flux_of_ ...  [kg m-2 s-1]

There are 4 terms, e.g. 
surface_net_downward_mass_flux_of_carbon_dioxide_expressed_as_13C_due_to_all_land_processes,
 which refer to the "net_downward" mass flux. Most carbon mass flux terms 
simply refer to the downward mass flux (e.g. 
surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon). "net" is 
included in radiation terms to avoid confusion with upwelling and downwelling 
fluxes, but the usage here with a mass flux appears anomalous. Should this be 
shortened (slightly) to 
surface_downward_mass_flux_of_carbon_dioxide_expressed_as_13C_due_to_all_land_processes?


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] parametric vertical coordinate standard_name confusion

[Martin Juckes - UKRI STFC]

Hi Karl,


I think it is in there (table A.1) .. between "compress" and "Conventions",


regards,

Martin



From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 07 March 2019 00:49
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] parametric vertical coordinate standard_name confusion

HI all,

I hope someone can provide some help here:

In Appendix D of the conventions where parametric vertical coordinates
are discussed, a "computed_standard_name" attribute is defined for some
coordinates, but "computed_standard_name" doesn't appear in Appendix A.
Should it?

Also does computed_standard_name get attached to the coordinate variable
along with the actual standard_name of the coordinate variable?

thanks,
Karl

___
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

Re: [CF-metadata] too many eddies in standard names

[Martin Juckes - UKRI STFC]

Hello Jonathan,


I agree that using "eddy" in terms which relate to vertical mixing is not 
ideal. It is not entirely incorrect, but I I think most people associate the 
term "eddy" with horizontal motions and so it is likely to cause confusion.


The current definition:

'"Eddy dianeutral mixing" means dianeutral mixing, i.e. mixing across neutral 
directions caused by the unresolved turbulent motion of eddies of all types 
(e.g., breaking gravity waves, boundary layer turbulence, etc.).'

would then need to be replaced with something like:

'"Dianeutral mixing" refers to mixing across surfaces of neutral bouyancy. 
"Parameterized"  means the part due to a scheme representing processes which 
are not explicitly resolved by the model.'

regards,
Martin




From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 04 March 2019 17:52
To: cf-metadata@cgd.ucar.edu
Cc: stephen.griff...@noaa.gov
Subject: Re: [CF-metadata] too many eddies in standard names

Dear Martin, Alison, Steve et al.

You're quite right. I had completely forgotten this discussion. That reduces my
concern a lot! Thanks. On 19 May 2017
(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/019440.html, subject
"New standard names for OMIP: physics" for this and related emails)
I agreed with Alison and Steve Griffies that parameterized mesoscale advection
(often Gent-McWilliams in ocean models) and parameterized submesoscale
advection should have "eddy" included because they are contributions to
parameterized eddy advection, and that parameterized mesoscale diffusion (often
called "isopycnal diffusion" in ocean models) could also have eddy included by
analogy. However this email didn't talk about inserting "eddy" in the
dianeutral mixing names. Alison suggested this on 12 Oct 2017
(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/019683.html)
and I didn't notice - sorry about that. There are three such names:

tendency_of_sea_water_conservative_temperature_expressed_as_heat_content_due_to_parameterized_eddy_dianeutral_mixing
tendency_of_sea_water_potential_temperature_expressed_as_heat_content_due_to_parameterized_eddy_dianeutral_mixing
tendency_of_sea_water_salinity_expressed_as_salt_content_due_to_parameterized_eddy_dianeutral_mixing

which as proposed did not contain "eddy". These quantities do not refer to
eddies in the sense of the other ones, and I suggest we should remove the eddy
in the standard names. I wonder what you all think.

Best wishes

Jonathan


- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Sun, 3 Mar 2019 21:40:02 +
> From: Martin Juckes - UKRI STFC 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] too many eddies in standard names
>
> Dear Jonathan,
>
>
> The CMIP6 Data Request uses the terms which are in the CF Standard Name list 
> ... with "eddy_advection".
>
>
> The CF Standard Name editor link for one of the terms is here: 
> <https://docs.google.com/presentation/d/1Enafy971fSF3mNJb5MObm3buH2yAmamMkRcj5h9WmJM/edit#slide=id.p>
>   
> http://cfeditor.ceda.ac.uk/proposal/1795.<http://cfeditor.ceda.ac.uk/proposal/1795>
>
>
> The email thread is here (the link from the editor is broken): 
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/019691.html 
> .<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/019691.html>
>
>
> I'm not sure if I've followed all the details ... but it looks as though 
> Alison proposed adding "eddy" and her proposal was accepted.
>
>
> regards,
>
> Martin
>
>
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 01 March 2019 17:45
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] too many eddies in standard names
>
> Dear Martin
>
> The names did get approved on the email list in the usual way. However, some-
> thing must have gone wrong somewhere. Either the names we asked to be approved
> were wrong (not the same as the ones in the papers, which is what we 
> intended),
> or the names in the standard_name table aren't the ones that were approved -
> which seems unlikely. I'm quite prepared to find that it was my mistake some-
> where! Anyway, I think it could be put right with aliases. What do we have in
> the CMIP6 data request?
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Martin Juckes - UKRI STFC 
>  -
>
> > Date: Fri, 1 Mar 2019 08:39:54 +
> > From: Martin Juckes - UKRI STFC 
> > To: "Taylor, Karl E." , "cf-metadata@cgd.ucar.edu"
> >
> > Subject: Re: [CF-metadata] too many eddies in standard names
> >
> >

Re: [CF-metadata] angular areas

[Martin Juckes - UKRI STFC]

Hello Karl,


in udunits "sr", "steradian" and "radian^2", "radian2" are all equivalent. I 
think we could use "sr". This unit is already used in the term 
"volume_scattering_function_of_radiative_flux_in_air_due_to_ambient_aerosol_particles",
 which has units "m-1 sr-1" and is defined as a "flux per unit solid angle".


I believe the term "solid angle" is general enough to be used for an arbitrary 
shape: it is the area of a the shape projected onto a unit sphere.


It is clear from the context of your proposal that the quantity you are 
interested in is a solid angle relative to the Earth's centroid, whereas the 
solid angle in the definition of the term above is relative to the scattering 
particle. It may be worth considering making explicit reference to the fact 
that this term is a geocentric solid angle in the standard name, e.g. 
"solid_angle_from_geocenter" (analogous to the existing term 
"distance_from_geocenter").


regards,

Martin



From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 02 March 2019 17:36
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] angular areas

Hi all,

Certain conservative regridding applications use "angular area" in
mapping from a source to destination grid.  Some of these applications
record the areas in units of radians squared (i.e., they compute the
fraction of spherical area occupied by the grid cell and then multiply
it by 4*pi.

I would like to define a new standard name to use with these "angular
areas".  Would the following be appropriate?

standard_name = "solid_angle"
units = "steradian" (abbrev. "sr")

Is "solid_angle" general enough to represent any shaped region on the
spherical surface?
Does udunits allow "sr", or should it be "radian**2"

best wishes,
Karl
___
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

Re: [CF-metadata] too many eddies in standard names

[Martin Juckes - UKRI STFC]

Dear Jonathan,


The CMIP6 Data Request uses the terms which are in the CF Standard Name list 
... with "eddy_advection".


The CF Standard Name editor link for one of the terms is here: 
<https://docs.google.com/presentation/d/1Enafy971fSF3mNJb5MObm3buH2yAmamMkRcj5h9WmJM/edit#slide=id.p>
  
http://cfeditor.ceda.ac.uk/proposal/1795.<http://cfeditor.ceda.ac.uk/proposal/1795>


The email thread is here (the link from the editor is broken): 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/019691.html 
.<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/019691.html>


I'm not sure if I've followed all the details ... but it looks as though Alison 
proposed adding "eddy" and her proposal was accepted.


regards,

Martin



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 01 March 2019 17:45
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] too many eddies in standard names

Dear Martin

The names did get approved on the email list in the usual way. However, some-
thing must have gone wrong somewhere. Either the names we asked to be approved
were wrong (not the same as the ones in the papers, which is what we intended),
or the names in the standard_name table aren't the ones that were approved -
which seems unlikely. I'm quite prepared to find that it was my mistake some-
where! Anyway, I think it could be put right with aliases. What do we have in
the CMIP6 data request?

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Fri, 1 Mar 2019 08:39:54 +
> From: Martin Juckes - UKRI STFC 
> To: "Taylor, Karl E." , "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] too many eddies in standard names
>
> Hello Jonathan, Karl,
>
>
> I don't understand why this is considered an "error" in the standard names. 
> There are many cases where people have put terms in their GMD papers and 
> claimed that they are "CF standard names" without taking the trouble to put 
> them through the discussion and approval process of the CF Convention. This 
> is a clear procedural error which happened in several MIPs ... we obviously 
> need to improve communication on the procedures.
>
>
> In answer to Karl's question: there are no approved or aliased terms of the 
> form "mesoscale_advection" in the CF Standard Name list. The approved 
> terms  consistently use the form "mesoscale/submesoscale_eddy_advection".
>
>
> I didn't follow the discussion on these terms when they were added .. Alison 
> may be able to say more about why the "eddy" term is included,
>
>
> regards,
>
> Martin
>
>
>
>
> 
> From: CF-metadata  on behalf of Taylor, 
> Karl E. 
> Sent: 27 February 2019 21:47
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] too many eddies in standard names
>
> Hi Jonathan,
>
> One could conceivably want to distinguish between, for example,
>
> northward_ocean_heat_transport_due_to_parameterized_mesoscale_eddy_advection
>
> and
>
> northward_ocean_heat_transport_due_to_parameterized_mesoscale_advection
>
> or does "mesoscale" imply "eddy" and for that reason "eddy" can be removed?  
> If "mesocale eddy advection" and mesocale advection" are not identical, we 
> could leave the already defined variables as is and add a companion set with 
> "eddy" omitted.
>
> Of course for CMIP6, we would want to request only one of the two types of 
> advection; from your reference to GMD, I assume you want the quantity without 
> "eddy" in the name.
>
> best regards,
> Karl
>
>
>
> On 2/27/19 10:46 AM, Jonathan Gregory wrote:
> > Dear Alison, Martin et al.
> >
> > I have noticed that several of the new ocean tendency diagnostics we have
> > added to the standard name table for CMIP6 contain "eddy", but should not 
> > do.
> > The word "eddy" should appear only in parameterized_eddy_advection, not in
> > mesoscale advection, mesoscale diffusion, submesoscale advection or
> > dianeutral mixing. I think _eddy should be deleted from all of the names 
> > listed
> > below. I don't know how we got this wrong! The standard names appear 
> > correctly
> > in the two relevant GMD papers.
> >
> > Best wishes
> >
> > Jonathan
> >
> > northward_ocean_heat_transport_due_to_parameterized_mesoscale_eddy_advection
> > northward_ocean_heat_transport_due_to_parameterized_mesoscale_eddy_diffusion
> > northward_ocean_heat_transport_due_to_parameterized_submesoscale_eddy_advection
> > ocean_meridional_o

Re: [CF-metadata] too many eddies in standard names

[Martin Juckes - UKRI STFC]

Hello Jonathan, Karl,


I don't understand why this is considered an "error" in the standard names. 
There are many cases where people have put terms in their GMD papers and 
claimed that they are "CF standard names" without taking the trouble to put 
them through the discussion and approval process of the CF Convention. This is 
a clear procedural error which happened in several MIPs ... we obviously need 
to improve communication on the procedures.


In answer to Karl's question: there are no approved or aliased terms of the 
form "mesoscale_advection" in the CF Standard Name list. The approved terms 
 consistently use the form "mesoscale/submesoscale_eddy_advection".


I didn't follow the discussion on these terms when they were added .. Alison 
may be able to say more about why the "eddy" term is included,


regards,

Martin





From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 27 February 2019 21:47
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] too many eddies in standard names

Hi Jonathan,

One could conceivably want to distinguish between, for example,

northward_ocean_heat_transport_due_to_parameterized_mesoscale_eddy_advection

and

northward_ocean_heat_transport_due_to_parameterized_mesoscale_advection

or does "mesoscale" imply "eddy" and for that reason "eddy" can be removed?  If 
"mesocale eddy advection" and mesocale advection" are not identical, we could 
leave the already defined variables as is and add a companion set with "eddy" 
omitted.

Of course for CMIP6, we would want to request only one of the two types of 
advection; from your reference to GMD, I assume you want the quantity without 
"eddy" in the name.

best regards,
Karl



On 2/27/19 10:46 AM, Jonathan Gregory wrote:
> Dear Alison, Martin et al.
>
> I have noticed that several of the new ocean tendency diagnostics we have
> added to the standard name table for CMIP6 contain "eddy", but should not do.
> The word "eddy" should appear only in parameterized_eddy_advection, not in
> mesoscale advection, mesoscale diffusion, submesoscale advection or
> dianeutral mixing. I think _eddy should be deleted from all of the names 
> listed
> below. I don't know how we got this wrong! The standard names appear correctly
> in the two relevant GMD papers.
>
> Best wishes
>
> Jonathan
>
> northward_ocean_heat_transport_due_to_parameterized_mesoscale_eddy_advection
> northward_ocean_heat_transport_due_to_parameterized_mesoscale_eddy_diffusion
> northward_ocean_heat_transport_due_to_parameterized_submesoscale_eddy_advection
> ocean_meridional_overturning_mass_streamfunction_due_to_parameterized_mesoscale_eddy_advection
> ocean_meridional_overturning_mass_streamfunction_due_to_parameterized_submesoscale_eddy_advection
> ocean_tracer_biharmonic_diffusivity_due_to_parameterized_mesoscale_eddy_advection
> ocean_tracer_diffusivity_due_to_parameterized_mesoscale_eddy_advection
> ocean_tracer_laplacian_diffusivity_due_to_parameterized_mesoscale_eddy_advection
> ocean_y_overturning_mass_streamfunction_due_to_parameterized_mesoscale_eddy_advection
> ocean_y_overturning_mass_streamfunction_due_to_parameterized_submesoscale_eddy_advection
> tendency_of_sea_water_conservative_temperature_expressed_as_heat_content_due_to_parameterized_eddy_dianeutral_mixing
> tendency_of_sea_water_conservative_temperature_expressed_as_heat_content_due_to_parameterized_mesoscale_eddy_advection
> tendency_of_sea_water_conservative_temperature_expressed_as_heat_content_due_to_parameterized_mesoscale_eddy_diffusion
> tendency_of_sea_water_conservative_temperature_expressed_as_heat_content_due_to_parameterized_submesoscale_eddy_advection
> tendency_of_sea_water_potential_temperature_expressed_as_heat_content_due_to_parameterized_eddy_dianeutral_mixing
> tendency_of_sea_water_potential_temperature_expressed_as_heat_content_due_to_parameterized_mesoscale_eddy_advection
> tendency_of_sea_water_potential_temperature_expressed_as_heat_content_due_to_parameterized_mesoscale_eddy_diffusion
> tendency_of_sea_water_potential_temperature_expressed_as_heat_content_due_to_parameterized_submesoscale_eddy_advection
> tendency_of_sea_water_salinity_expressed_as_salt_content_due_to_parameterized_eddy_dianeutral_mixing
> tendency_of_sea_water_salinity_expressed_as_salt_content_due_to_parameterized_mesoscale_eddy_advection
> tendency_of_sea_water_salinity_expressed_as_salt_content_due_to_parameterized_mesoscale_eddy_diffusion
> tendency_of_sea_water_salinity_expressed_as_salt_content_due_to_parameterized_submesoscale_eddy_advection
> ___
> 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

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Hello Karl,


"other dimensionless representations" are common in volume fractions, e.g. 
1.e-6 (ppm). This is not usually used for area fractions, but it is allowed.


regards,

Martin


From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 12 February 2019 06:08:31
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
area_fraction

Hi Alison,

Looks good to me.

Perhaps Martin can weigh in on whether or not the phrase "or any other
dimensionless representation of a fraction" is needed.  Are there any
such entities?

best regards,
Karl

On 2/11/19 11:14 AM, Alison Pamment - UKRI STFC wrote:
> Dear Karl,
>
> I like that definition - it gives a clear explanation of the purpose of the 
> name as well as the acceptable ways of expressing the fraction.
>
> We should also retain the existing text about the use of area_type or more 
> specific X_area_fraction names to specify *which* area is being quantified. 
> So then we'd have:
> ' "Area fraction" is the fraction of a grid cell's horizontal area that has 
> some characteristic of interest.  It is evaluated as the area of interest 
> divided by the grid cell area.  It may be expressed as a fraction, a 
> percentage, or any other dimensionless representation of a fraction. To 
> specify which area is quantified by a variable with standard name 
> area_fraction, provide a coordinate variable or scalar coordinate variable 
> with standard name area_type. Alternatively, if one is defined, use a more 
> specific standard name of X_area_fraction for the fraction of horizontal area 
> occupied by X. '
>
>   (Out of curiosity I tried entering k% into UDunits. Not too surprisingly it 
> responded with "Don't recognize " k%" ").
>
> Best wishes,
> Alison
>
> --
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
>
> -Original Message-
> From: CF-metadata  On Behalf Of Taylor, 
> Karl E.
> Sent: 07 February 2019 17:24
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
> area_fraction
>
> HI Martin and all,
>
> I agree that the best option is to modify the text.  In that regard, I 
> stumbled over the word "proportional" ... proportional to what? Also, only 
> udunits experts will recognize that "1" has a specific meaning when appearing 
> as a unit, so "conforms to 1" might be unclear.  Would something like the 
> following be better?
>
> "Area Fraction" is the fraction of a grid cell's horizontal area that has 
> some characteristic of interest.  It is evaluated as the area of interest 
> divided by the grid cell area.  It may be expressed as a fraction, a 
> percentage, or any other dimensionless representation of a fraction."
>
> By the way, off hand I can't think of "other dimensionless representations of 
> a fraction"  Is kilo-percent (k%) legal?
>
> regards,
> Karl
>
> On 2/7/19 8:57 AM, Martin Juckes - UKRI STFC wrote:
>> Dear Jonathan,
>>
>> Thanks, that justification will be helpful in replying to people.
>>
>> To summarise, the proposal (now backed by Jonathan and John -- after 
>> dropping the idea of changing the standard name) is that the current text 
>> '"Area fraction" means the fraction of horizontal area.' in the description 
>> of the standard name "area_fraction" should be replaced with the following:
>> "Area Fraction" is a dimensionless number representing a relative or 
>> proportional area. It may be expressed as a fraction, percentage or any 
>> other unit that conforms to "1".  It is evaluated as the area of interest 
>> divided by the grid cell area, scaled for the units chosen.
>>
>> regards,
>> Martin
>>
>> 
>> From: CF-metadata  on behalf of
>> Jonathan Gregory 
>> Sent: 06 February 2019 21:23
>> To: cf-metadata@cgd.ucar.edu
>> Subject: [CF-metadata] Putting the units in a CF standard name:
>> area_fraction
>>
>> Dear Martin
>>
>> I would say yes, that the use of "fraction" in area_fraction is for
>> consistency with all the other uses of "fraction" in standard names
>> (mass, mole, time and volume). In addition I would say that "cover"
>> would be a confusing word to use, because "land cover" often means
>> "land surface 

[CF-metadata] Surfaces under ice vs. above ice : sea water surface vs surface in standard names.

[Martin Juckes - UKRI STFC]

Dear All,


while reviewing CMIP6 metadata specifications I came across a few anomalies 
regarding the distinction between the upper surface of the liquid ocean (which 
may be under ice) vs. the lower surface of the atmosphere (which would be above 
the ice).

(1) sea_water_pressure_at_sea_water_surface and
net_downward_shortwave_flux_at_sea_water_surface;

The names of these two terms suggest that they are intended to be different 
from, for example, surface_net_downward_shortwave_flux. They have been 
requested by OMIP for diagnostics which are intended to represent the air/sea 
or ice/sea interface, on the air/ice interface. The problem is that the 
descriptions use the standard phrase 'The surface called "surface" means the 
lower boundary of the atmosphere', which is wrong in this case. Can this be 
changed to: 'The phrase "sea water surface" means the upper boundary of the 
liquid portion of an ocean or sea, including the boundary to floating ice if 
present.'

(2) surface_downward_x/y_stress and surface_downward_x/y_stress_correction;

There is nothing wrong with these terms, but they have been wrongly used to 
represent stresses applied to the liquid ocean. To correct this we need four 
new terms. I propose using the "_at_sea_water_surface" construction, based on 
the two terms above:

  *   downward_x_stress_at_sea_water_surface
  *   downward_y_stress_at_sea_water_surface
  *   downward_x_stress_correction_at_sea_water_surface
  *   downward_y_stress_correction_at_sea_water_surface

As above, the description should include the sentence:
'The phrase "sea water surface" means the upper boundary of the liquid portion 
of an ocean or sea, including the boundary to floating ice if present.'

regards,
Martin


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Dear Jonathan,

Thanks, that justification will be helpful in replying to people.

To summarise, the proposal (now backed by Jonathan and John -- after dropping 
the idea of changing the standard name) is that the current text '"Area 
fraction" means the fraction of horizontal area.' in the description of the 
standard name "area_fraction" should be replaced with the following:
"Area Fraction" is a dimensionless number representing a relative or 
proportional area. It may be expressed as a fraction, percentage or any other 
unit that conforms to "1".  It is evaluated as the area of interest divided by 
the grid cell area, scaled for the units chosen.

regards,
Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 06 February 2019 21:23
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Putting the units in a CF standard name: area_fraction

Dear Martin

I would say yes, that the use of "fraction" in area_fraction is for consistency
with all the other uses of "fraction" in standard names (mass, mole, time and
volume). In addition I would say that "cover" would be a confusing word to use,
because "land cover" often means "land surface type". Finally, I would say to
experts who are offended that in this case, as in plenty of others where CF has
not quite followed familiar terminology in the domain, there is no implication
that anyone thinks they are "wrong" in their terminology. It's just that CF is
used across a wide range of disciplines and as far as possible all of it has to
be consistent and intelligible to everyone.

Best wishes

Jonathan


- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Wed, 6 Feb 2019 12:16:06 +
> From: Martin Juckes - UKRI STFC 
> To: John Graybeal , Jim Biard 
> Cc: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] Putting the units in a CF standard name:
>area_fraction
>
> Hello John, others,
>
>
> Thanks for those comments. I can see the value of maintaining consistency and 
> being careful about changing things which have worked well for a long time, 
> but I would rather not go back to the people who find the existing 
> terminology confusing (these are people who have specifically commented on 
> the standard name area_fraction) and tell them that we are not changing it 
> because it has always been like that. I'd rather have a more positive message 
> that might encourage them to appreciate the value of CF.
>
>
> I'm not sure if this is true, but it looks to me as though the formulation 
> "area_fraction" owes something to "volume_fraction", "mass_fraction" and 
> "mole_fraction", all of which follow wide spread usage in the atmospheric and 
> oceanographic science communities. People who use mass and volume fractions 
> appear to be accustomed to having these expressed as percentages outside CF, 
> so it is no surprise to find this done in CF. For "area_fraction" we have a 
> slightly different situation: the term doesn't arise from expressions used in 
> the land surface science communities, rather it is a semantic structure being 
> imposed on them. Does anyone now if this interpretation is correct (i.e. that 
> we use "area_fraction" rather than something which might be more familiar for 
> land surface scientists such as "area_cover" in order to maintain consistency 
> with mass, volume and mole fractions)?
>
>
> regards,
>
> Martin
>
>
>
> 
> From: CF-metadata  on behalf of John 
> Graybeal 
> Sent: 01 February 2019 07:12
> To: Jim Biard
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
> area_fraction
>
> Martin,
>
> I like your definition.
>
> While there is a case for renaming the standard name, it’s long-time use, 
> validity, and the fact only sophisticated data managers use standard names 
> (and most data users just look primarily at variable names) says to me we 
> should keep the existing standard names with fraction.
>
> John
>
> On Jan 31, 2019, at 08:07, Jim Biard 
> mailto:jbi...@cicsnc.org>> wrote:
>
>
> Hi.
>
> I understand that concern, but it has always been true that the units for a 
> quantity identified by a standard name only has to be convertible using 
> UDUNITS from the canonical units specified in the definition for that 
> standard name. So percent is, by definition, valid for a quantity with units 
> of '1'. As you can see below:
>
> > udunits2
> You have: 1
> You want: percent
> 1  = 100 percent
> x/percent = 100*(x/)
>
> I guess I don't see

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Hello John, others,


Thanks for those comments. I can see the value of maintaining consistency and 
being careful about changing things which have worked well for a long time, but 
I would rather not go back to the people who find the existing terminology 
confusing (these are people who have specifically commented on the standard 
name area_fraction) and tell them that we are not changing it because it has 
always been like that. I'd rather have a more positive message that might 
encourage them to appreciate the value of CF.


I'm not sure if this is true, but it looks to me as though the formulation 
"area_fraction" owes something to "volume_fraction", "mass_fraction" and 
"mole_fraction", all of which follow wide spread usage in the atmospheric and 
oceanographic science communities. People who use mass and volume fractions 
appear to be accustomed to having these expressed as percentages outside CF, so 
it is no surprise to find this done in CF. For "area_fraction" we have a 
slightly different situation: the term doesn't arise from expressions used in 
the land surface science communities, rather it is a semantic structure being 
imposed on them. Does anyone now if this interpretation is correct (i.e. that 
we use "area_fraction" rather than something which might be more familiar for 
land surface scientists such as "area_cover" in order to maintain consistency 
with mass, volume and mole fractions)?


regards,

Martin




From: CF-metadata  on behalf of John Graybeal 

Sent: 01 February 2019 07:12
To: Jim Biard
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
area_fraction

Martin,

I like your definition.

While there is a case for renaming the standard name, it’s long-time use, 
validity, and the fact only sophisticated data managers use standard names (and 
most data users just look primarily at variable names) says to me we should 
keep the existing standard names with fraction.

John

On Jan 31, 2019, at 08:07, Jim Biard 
mailto:jbi...@cicsnc.org>> wrote:


Hi.

I understand that concern, but it has always been true that the units for a 
quantity identified by a standard name only has to be convertible using UDUNITS 
from the canonical units specified in the definition for that standard name. So 
percent is, by definition, valid for a quantity with units of '1'. As you can 
see below:

> udunits2
You have: 1
You want: percent
1  = 100 percent
x/percent = 100*(x/)

I guess I don't see the need for guidance here.

Grace and peace,

Jim

On 1/31/19 10:51 AM, Martin Juckes - UKRI STFC wrote:

Dear Jonathan,


we could certainly take that approach, though the definitions are not always 
accessible to people looking at the standard name, so they do not compensate 
for ambiguity in the name itself.


The current text '"Area fraction" means the fraction of horizontal area.' could 
be replaced with


"Area Fraction" is a dimensionless number representing a relative or 
proportional area. It may be expressed as a fraction, percentage or any other 
unit that conforms to "1".  It is evaluated as the area of interest divided by 
the grid cell area, scaled for the units chosen.


I still feel that there is a case for changing the name to, for example, 
"relative_area" in order to reduce confusion caused by people who assume that a 
fraction is a quantity that does not have units,


regards,

Martin





From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jonathan Gregory 
<mailto:j.m.greg...@reading.ac.uk>
Sent: 31 January 2019 13:20:24
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: [CF-metadata] Putting the units in a CF standard name: area_fraction

Dear Martin

I'd rather we retained "fraction" in the standard name, because it's always
been there, it's used in other contexts in a consistent way, and there isn't
anything actually incorrect with it, as you say. Could we instead add a note
to the definitions pointing out that percent is acceptable as a unit for them?

Best wishes

Jonathan

----- Forwarded message from Martin Juckes - UKRI STFC 
<mailto:martin.juc...@stfc.ac.uk> -



Date: Wed, 30 Jan 2019 22:40:12 +
From: Martin Juckes - UKRI STFC 
<mailto:martin.juc...@stfc.ac.uk>
To: Steven Emmerson <mailto:emmer...@ucar.edu>
Cc: "CF-metadata (cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>)" 
<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Putting the units in a CF standard name:
   area_fraction

Hi Steve,


The issue is more that CF allows more freedom in the choice of units than many 
people expect from a "fraction".


A second problem, I think the problem is that I didn't explain the issue 
clearly. In 

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Hi Steve,


yes, but I was suggesting a change in the standard name ... you seemed to be 
suggesting not using it, which would leave variables without a standard name.


regards,

Martin






From: Steven Emmerson 
Sent: 31 January 2019 18:27
To: Juckes, Martin (STFC,RAL,RALSP); CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
area_fraction

Martin,

On Thu, Jan 31, 2019 at 9:32 AM Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> wrote:
In the interests of clarity, could you say why the option I've proposed is not 
in your list?

I'm sorry. I thought you proposed not using the word "fraction", so that, for 
example, "area_fraction" would become something like "relative_area".

Regards,
Steve Emmerson
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Hi Steve,


In the interests of clarity, could you say why the option I've proposed is not 
in your list?


I'm not convinced that adopting your choice 2. will promote common language 
among disciplines. It is a laudable aim, but I fell it would be better taking 
into account the way in which are standard is perceived by others.


regards,

Martin





From: Steven Emmerson 
Sent: 31 January 2019 16:02
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
area_fraction

Martin,

So, it would seem like the potential solutions to the problem you perceive are

  1.  Not use the standard name "fraction" in variable names to accommodate 
people who are confused when the values are given in percent; or
  2.  Use the standard name "fraction" and expect people to learn.

I favor #2 because it promotes a common language amongst disciplines.

Regards,
Steve Emmerson


On Wed, Jan 30, 2019 at 3:40 PM Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> wrote:
Hi Steve,


The issue is more that CF allows more freedom in the choice of units than many 
people expect from a "fraction".


A second problem, I think the problem is that I didn't explain the issue 
clearly. In the CMIP data request we are specifying that variables with 
standard name "area_fraction" should be given as percentages. This is allowed 
by the CF convention: an "area_fraction" can be 0.5 or 50%. The reason that 
percentages are being used is because "area_fraction" is being used like the 
proportion of land covered in grass, and people are used to having these as 
percentages rather than fractions. It is all perfectly correct as far as the 
convention goes, but people often interpret the use of "area_fraction" for a 
percentage as an error.


Given that we have the framework of allowing flexibility in the choice of 
units, I feel it would be better to avoid having the term "fraction" in the 
standard name, given that it is often interpreted as implying a specific choice 
for the units.


regards,

Martin



From: Steven Emmerson mailto:emmer...@ucar.edu>>
Sent: 30 January 2019 21:37
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: CF-metadata (cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>)
Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
area_fraction

On Wed, Jan 30, 2019 at 12:54 PM Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk><mailto:martin.juc...@stfc.ac.uk<mailto:martin.juc...@stfc.ac.uk>>>
 wrote:

I'm afraid I don't understand your comment. When I search for "fraction" in the 
NIST document I find it defined as being a ratio, which is inconsistent with 
the current CF usage. The CF standard name concept "area_fraction" is not what 
NIST or others understand as a "fraction". I'm suggesting a change to remove 
this inconsistency.

Unless we're talking past one another, I'll have to disagree.  The NIST unit 
for "mass fraction" is "1" -- even though it's a ratio. A fraction can be 
represented many ways. "1:2", "1/2", and "0.5" all represent the same fraction, 
for example.

Does the CF convention require a particular representation for a fraction?

Regards,
Steve Emmerson
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Dear Jonathan,


we could certainly take that approach, though the definitions are not always 
accessible to people looking at the standard name, so they do not compensate 
for ambiguity in the name itself.


The current text '"Area fraction" means the fraction of horizontal area.' could 
be replaced with


"Area Fraction" is a dimensionless number representing a relative or 
proportional area. It may be expressed as a fraction, percentage or any other 
unit that conforms to "1".  It is evaluated as the area of interest divided by 
the grid cell area, scaled for the units chosen.


I still feel that there is a case for changing the name to, for example, 
"relative_area" in order to reduce confusion caused by people who assume that a 
fraction is a quantity that does not have units,


regards,

Martin





From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 31 January 2019 13:20:24
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Putting the units in a CF standard name: area_fraction

Dear Martin

I'd rather we retained "fraction" in the standard name, because it's always
been there, it's used in other contexts in a consistent way, and there isn't
anything actually incorrect with it, as you say. Could we instead add a note
to the definitions pointing out that percent is acceptable as a unit for them?

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Wed, 30 Jan 2019 22:40:12 +
> From: Martin Juckes - UKRI STFC 
> To: Steven Emmerson 
> Cc: "CF-metadata (cf-metadata@cgd.ucar.edu)" 
> Subject: Re: [CF-metadata] Putting the units in a CF standard name:
>area_fraction
>
> Hi Steve,
>
>
> The issue is more that CF allows more freedom in the choice of units than 
> many people expect from a "fraction".
>
>
> A second problem, I think the problem is that I didn't explain the issue 
> clearly. In the CMIP data request we are specifying that variables with 
> standard name "area_fraction" should be given as percentages. This is allowed 
> by the CF convention: an "area_fraction" can be 0.5 or 50%. The reason that 
> percentages are being used is because "area_fraction" is being used like the 
> proportion of land covered in grass, and people are used to having these as 
> percentages rather than fractions. It is all perfectly correct as far as the 
> convention goes, but people often interpret the use of "area_fraction" for a 
> percentage as an error.
>
>
> Given that we have the framework of allowing flexibility in the choice of 
> units, I feel it would be better to avoid having the term "fraction" in the 
> standard name, given that it is often interpreted as implying a specific 
> choice for the units.
>
>
> regards,
>
> Martin
>
>
> 
> From: Steven Emmerson 
> Sent: 30 January 2019 21:37
> To: Juckes, Martin (STFC,RAL,RALSP)
> Cc: CF-metadata (cf-metadata@cgd.ucar.edu)
> Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
> area_fraction
>
> On Wed, Jan 30, 2019 at 12:54 PM Martin Juckes - UKRI STFC 
> mailto:martin.juc...@stfc.ac.uk>> wrote:
>
> I'm afraid I don't understand your comment. When I search for "fraction" in 
> the NIST document I find it defined as being a ratio, which is inconsistent 
> with the current CF usage. The CF standard name concept "area_fraction" is 
> not what NIST or others understand as a "fraction". I'm suggesting a change 
> to remove this inconsistency.
>
> Unless we're talking past one another, I'll have to disagree.  The NIST unit 
> for "mass fraction" is "1" -- even though it's a ratio. A fraction can be 
> represented many ways. "1:2", "1/2", and "0.5" all represent the same 
> fraction, for example.
>
> Does the CF convention require a particular representation for a fraction?
>
> Regards,
> Steve Emmerson
> ___
> 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

Re: [CF-metadata] CMIP6 Confusion regarding carbon flux units

[Martin Juckes - UKRI STFC]

Dear Chris, All,


I think I should start by explaining some context for the benefit of those on 
this list that are not familiar with CMIP or the CMIP6 Data Request.


Chris is leading an international science team (C4MIP) 
that is participating in the CMIP6 model intercomparison project, as one of 
over 20 science teams. It has been decided, at quite a high level, based on 
positive experience in previous CMIP projects, that data should be archived in 
CF compliant netcdf files, and I have the dubious honour of coordinating the 
effort to specify CF compliant netCDF metadata for all the data which will be 
archived. The document which specifies this metadata for each variable is the 
"Data Request" which Chris refers to.


C4MIP deals, among other things, with emissions of greenhouse gasses. In order 
to minimise the widespread confusion between amounts expressed in terms of (a) 
mass of carbon in carbon dioxide and (b) mass of carbon dioxide itself, the 
C4MIP community has taken to expressing quantities in units of "kgC " when 
mass of carbon is intended. Hence Chris's request for this unit to be 
admissible in the CF Convention (which is a requirement for having it in the 
Data Request).


I don't support this approach myself, but as I have already shared my views 
with Chris, it would be interesting now to hear what others on the list think,


regards,

Martin



From: CF-metadata  on behalf of Jones, Chris 
D 
Sent: 31 January 2019 09:38
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] CMIP6 Confusion regarding carbon flux units


Dear Martin, dear All,



it is emerging that groups are making errors in implementing the carbon cycle 
data requests - especially regarding the units of carbon fluxes.



The issue is confusion over whether to report kg of CARBON or kg of CO2.



The intended correct answer is buried deep within the long name, where fluxes 
are described as, “…. flux of CO2 expressed as carbon …”. But unless you know 
where to look this is rather hidden and is resulting in groups mixing units of 
carbon and CO2 across variables.



So this is a request - actually a plea - that we revisit the decision to 
include the quantity in the units definition. I have heard the arguments that 
“kg C” is not an SI unit and we just need to explain it in the long name - but 
this is really not working and is causing real confusion and errors.



So PLEASE, PLEASE, can we re-define the labels for carbon fluxes and stores in 
terms of “kgC m-2 s-1” etc. ?



There has been such a massive effort to both define and implement this data 
request it would be a huge shame if substantial errors came in at the last 
minute - this small change will prevent that.



thanks,

Chris







--
Dr Chris Jones
Head, Earth System and Mitigation Science Team
Met Office Hadley Centre, FitzRoy Road, Exeter, EX1 3PB, U.K.
Tel: +44 (0)1392 884514  Fax: +44 (0)1392 885681
E-mail: chris.d.jo...@metoffice.gov.uk  
http://www.metoffice.gov.uk


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Hi Steve,


The issue is more that CF allows more freedom in the choice of units than many 
people expect from a "fraction".


A second problem, I think the problem is that I didn't explain the issue 
clearly. In the CMIP data request we are specifying that variables with 
standard name "area_fraction" should be given as percentages. This is allowed 
by the CF convention: an "area_fraction" can be 0.5 or 50%. The reason that 
percentages are being used is because "area_fraction" is being used like the 
proportion of land covered in grass, and people are used to having these as 
percentages rather than fractions. It is all perfectly correct as far as the 
convention goes, but people often interpret the use of "area_fraction" for a 
percentage as an error.


Given that we have the framework of allowing flexibility in the choice of 
units, I feel it would be better to avoid having the term "fraction" in the 
standard name, given that it is often interpreted as implying a specific choice 
for the units.


regards,

Martin



From: Steven Emmerson 
Sent: 30 January 2019 21:37
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
area_fraction

On Wed, Jan 30, 2019 at 12:54 PM Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> wrote:

I'm afraid I don't understand your comment. When I search for "fraction" in the 
NIST document I find it defined as being a ratio, which is inconsistent with 
the current CF usage. The CF standard name concept "area_fraction" is not what 
NIST or others understand as a "fraction". I'm suggesting a change to remove 
this inconsistency.

Unless we're talking past one another, I'll have to disagree.  The NIST unit 
for "mass fraction" is "1" -- even though it's a ratio. A fraction can be 
represented many ways. "1:2", "1/2", and "0.5" all represent the same fraction, 
for example.

Does the CF convention require a particular representation for a fraction?

Regards,
Steve Emmerson
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Hi Steve,


I'm afraid I don't understand your comment. When I search for "fraction" in the 
NIST document I find it defined as being a ratio, which is inconsistent with 
the current CF usage. The CF standard name concept "area_fraction" is not what 
NIST or others understand as a "fraction". I'm suggesting a change to remove 
this inconsistency,


regards,

Martin



From: Steven Emmerson 
Sent: 30 January 2019 17:27
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
area_fraction

On Wed, Jan 30, 2019 at 7:36 AM Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> wrote:
Could we avoid this confusion in the future by replacing the term with a more 
neutral term, such as "area_cover"?

That would be inconsistent with the NIST recommendation. See 
<https://www.nist.gov/physical-measurement-laboratory/nist-guide-si-chapter-8>. 
Search for "fraction".

Regards,
Steve Emmerson
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Putting the units in a CF standard name: area_fraction

[Martin Juckes - UKRI STFC]

Hello,


I've just been writing a short note to explain that a standard name of 
"area_fraction" doesn't necessarily mean that the quantity referred to is a 
fraction ... it could be a percentage, for instance.  I've done this quite 
regularly over the last few years, because we are using this term in the CMIP6 
data request for variables, and specifying that they should be archived as 
percentages.


The most widely used meaning of fraction is the straight ratio of two terms. 
Using to express a portion in arbitrary units (specified by the units 
attribute) is not wrong, as this is an accepted meaning of "fraction", but it 
is confusing.


Could we avoid this confusion in the future by replacing the term with a more 
neutral term, such as "area_cover"?


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Two [simple] questions

[Martin Juckes - UKRI STFC]

Hello Lars,


  1.  Here you have two options for providing exactly equivalent information, 
and the choice is yours. I don't think there is any general reason to prefer 
one over the other. If you use the "amount", I believe you should have 
cell_methods "time: sum" and a time bounds variable. With "rate", on the other 
hand, you need cell_methods "time: mean", and time bounds variable. You need 
the time bounds variable in both cases: setting the units to "mm day-1" just 
specifies the unit of measure and doesn't tell the user that it is a 
representing the daily rainfall.
  2.  I'd advise sticking to ASCII for the title. I recently wrote a "guide" 
setting out some rules used for variables in CMIP6: 
https://zenodo.org/record/2480853 .. I'd be interested in your comments on 
that. In CMIP6, as in CMIP5, we have tended not to include "daily" in the long 
names -- mainly because it is easier to use a fixed long name across multiple 
frequencies.

regards,
Martin



From: CF-metadata  on behalf of Bärring Lars 

Sent: 24 January 2019 14:13
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Two [simple] questions

Dear all,

Two simple questions of understanding:

1. If I have (observed) daily precipitation with unit mm/day and want to store 
this in a CF compliant file, should I use standard name
--- "lwe_thickness_of_precipitation_amount" with canonical unit metre and the 
"per day" part is inferred from the time bounds, or
--- "lwe_precipitation_rate" having canonical unit "m s-1",
--- if both are acceptable, is one to be preferred?


2. The long_name is free, but should be descriptive. I am thinking of this as a 
succinct plot title, so the question is what practical limitation there might 
be in relation to different software. Is it advisable to use ASCII spaces (from
Github issue #141 indicates that only standard ASCII character set should be 
used) ?


Many thanks,

Lars

--
Lars Bärring

FDr, Forskare
PhD, Research Scientist

SMHI  /  Swedish Meteorological and Hydrological Institute
Rossby Centre
SE - 601 76 NORRKÖPING
http://www.smhi.se

E-post / Email: lars.barr...@smhi.se
Tel / Phone: +46 (0)11 495 8604
Fax: +46 (0)11 495 8001
Besöksadress / Visiting address: Folkborgsvägen 17
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new standard name for solar-induced chlorophyll fluorescence

[Martin Juckes - UKRI STFC]

Dear Ranjini, Alison,


I'd like to propose a further modification to Alison's suggestion. Firstly, 
after reading a little about SIF (this is a useful description: 
http://terraluma.net/applications-2/uas-spectrometry-for-sun-induced-chlorophyll-fluorescence-retrieval/
 ) I feel that the "photosynthetic" in "_photosynthetic_radiance_" is 
inappropriate here: the SIF is a small fraction (around 1%) of the incident 
photosynthetic radiation (less than the reflected component) and it has a 
different wavelength distribution.  It is also redundant in this term, so 
"photosynthetic" can be left out. Secondly, SIF is often defined as "Solar 
Induced Flourescence", since adding chlorophyll is redundant. Hence, a shorter 
name could be used:


toa_outgoing_radiance_per_unit_wavelength_due_to_solar_induced_fluorescence 
(Canonical units: W m-2 sr-1 m-1)


'The abbreviation "toa" means top of atmosphere. Radiance is the radiative flux 
in a particular direction, per unit of solid angle. The direction towards which 
it is going must be specified, for instance with a coordinate of zenith_angle. 
A coordinate variable for radiation wavelength should be given the standard 
name radiation_wavelength. The specification of a physical process by the 
phrase "due_to_" process means that the quantity named is a single term in a 
sum of terms which together compose the general quantity named by omitting the 
phrase. Some of the solar energy absorbed by pigment systems of plant leaves 
during photosynthesis is re-emitted as fluorescence. This is called 
solar-induced (chlorophyll) fluorescence (SIF). It is a radiance that can be 
measured on a global scale at various wavelengths and by multiple space borne 
instruments. SIF is considered a measurement of the photosynthetic machinery in 
plants and can provide a direct approach for the diagnosis of the actual 
 functional status of vegetation. It is therefore considered a functional proxy 
of terrestrial gross primary productivity which has the standard name 
gross_primary_productivity_of_biomass_expressed_as_carbon. SIF spans the 
wavelength range 600-800nm.'


Is there a standard wavelength that SIF is retrieved at?


It may be worth checking our definitions of "albedo". I think we have, in the 
past, assumed that "outgoing shortwave" was equivalent to "reflected". Hence, 
we have planetary_albedo defined in terms of the ratio of outgoing to incoming 
shortwave radiation: it should perhaps be the ratio of reflected to incoming 
shortwave radiation, which would exclude the contribution of fluorescence.


We also have a "bioluminescent_photon_rate_in_sea_water" name ... but I don't 
think that is closely related.


regards,

Martin




From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 06 December 2018 16:49
To: 'Ranjini Swaminathan'; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] new standard name for solar-induced chlorophyll 
fluorescence

Dear Ranjini,

Thank you for proposing this new standard name and apologies for the delay in 
getting back to you.

> Name : solar_induced_chlorophyll_fluorescence
> Canonical Units : W/m^2/sr/micron
>
> Description: Some of the solar energy absorbed by pigment systems of plant 
> leaves are reemitted as fluorescent photons. This signal is called 
> solar-induced cholorophyll fluorescence (SIF) , is a radiance and  can be 
> measured on a global scale at various
> wavelengths and by multiple space borne instruments. SIF is considered a 
> measurement of the the photosynthetic machinery in plants and can provide a 
> direct approach for the diagnosis of the actual functional status of 
> vegetation. It is therefore also
> considered a functional proxy of terrestrial Gross Primary Productivity.

Certainly we don't currently have a standard name for this quantity, so we will 
need to introduce a new one.

Where possible, we try to make new names consistent with existing ones and I 
found a few examples that may be helpful as templates for the quantity you are 
proposing .

Firstly, we have some existing names related to photosynthetic fluxes, for 
example:
fraction_of_surface_downwelling_photosynthetic_radiative_flux_absorbed_by_vegetation
 (Canonical Units: 1)
' Downwelling radiation is radiation from above. It does not mean "net 
downward". The sign convention is that "upwelling" is positive upwards and 
"downwelling" is positive downwards. The surface called "surface" means the 
lower boundary of the atmosphere. The quantity with standard name 
fraction_of_surface_downwelling_photosynthetic_radiative_flux_absorbed_by_vegetation,
 often called Fraction of Absorbed Photosynthetically Active Radiation (FAPAR), 
is the fraction of incoming solar radiation in the photosynthetically active 
radiation spectral region that is absorbed by a vegetation canopy. 
"Photosynthetic" radiation is the part of the spectrum which is used in 
photosynthesis e.g. 400-700 nm. The range of wavelengths could 

Re: [CF-metadata] New CMIP6 region names - WAS Addictional area types needed for CMIP6

[Martin Juckes - UKRI STFC]

Dear Alison,


yes, the new name is intended to be the complete area of the Pacific ocean plus 
the Indian ocean, and hence a greater area than the Indo-Pacific ocean. I 
support the proposal to add descriptions (as you say, I have proposed it 
before) ... I believe that these new names need some descriptions to avoid 
confusion,


regards,

Martin


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 05 December 2018 20:35:29
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New CMIP6 region names - WAS Addictional area types 
needed for CMIP6

Dear Martin and Karl,

Thanks for these new standardized_region proposals:
  *   indian_pacific_ocean (=Indian + Pacific)
  *   atlantic_arctic_ocean (=Atlantic + Arctic)

I think these proposals are okay as defined. I note, however, that the 
standardized region list already contains something called 
"indo_pacific_ocean". According to Wikipedia "indo-pacific"  is "a 
biogeographic region of Earth's seas, comprising the tropical waters of the 
Indian Ocean, the western and central Pacific Ocean, and the seas connecting 
the two in the general area of Indonesia. It does not include the temperate and 
polar regions of the Indian and Pacific oceans, nor the Tropical Eastern 
Pacific, along the Pacific coast of the Americas." I think this is different to 
what you are proposing as indian_pacific_ocean, which I assume means the whole 
of both the Indian and Pacific Oceans.

We do have an XML version of the region list, which I produced some months ago 
for reasons of machine-readability. (I believe Martin requested this).  It 
doesn't have any  tags at the moment, but it would be easy enough 
to add them in the same way as we do for area_types and standard names. This 
would allow us to also render  the list as an html table. It probably isn't 
necessary to add descriptions for most entries, but they could be added for 
those such as indo_pacific_ocean and indian_pacific_ocean where we might need 
to explain the difference. Do you think that would be a useful thing to do (and 
would it break any software if I add new tags to the XML)?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

-Original Message-
From: CF-metadata  On Behalf Of Taylor, Karl 
E.
Sent: 29 November 2018 01:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Addictional area types needed for CMIP6

Sorry for the misleading title in my recent posting.  The correct title now 
appears here,  copied from Martin's original posting (spelling error and all).
best,
Karl

On 11/28/18 4:47 PM, Taylor, Karl E. wrote:
> Dear Alison and all,
>
> I support Martin's proposal
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020666.html to
> add
>
> indian_pacific_ocean
> atlantic_arctic_ocean
>
> to the list of standard regions labels.
>
> best regards,
> Karl
>
> On 11/21/18 1:40 PM, Martin Juckes - UKRI STFC wrote:
>> Dear Jim,
>>
>>
>> sorry, I stand corrected. Thank you for the detailed explanation.
>>
>>
>> The conformance statements looks to be in error.
>>
>>
>> Is there a clear rule for what makes a valid set of flag_values when used in 
>> conjunction with flag_masks?
>>
>>
>> regards,
>>
>> Martin
>>
>>
>> 
>> From: Jim Biard 
>> Sent: 21 November 2018 20:50
>> To: Juckes, Martin (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
>> Subject: Re: [CF-metadata] Multiple zeros in flag_values allowed?
>>
>>
>> Martin,
>>
>> The two subfields are independent. You can have very bad quality data and 
>> very bad weather at the same time. And that's how the flag masks and flag 
>> values are supposed to work. The mask splits off bit regions that are 
>> independent of one another. There is no ambiguity.
>>
>> The possible options and the values masked by the flag masks of 3 (binary 
>> 0011) and 12 (binary 1100) are:
>>
>> Weather Quality
>>   Binary Value
>>   Binary value & 3
>>   Binary value & 12
>>
>> very bad
>>   very bad
>>   
>>   0
>>   0
>>
>> very bad
>>   bad
>>   0001
>>   1
>>   0
>>
>> very bad
>>   good
>>   0010
>>   2
>>   0
>>
>> very bad
>>   very good
>>   0011
>>   3
>>

[CF-metadata] Explaining the difference between "biomass growth" and "biomass maintenance"

[Martin Juckes - UKRI STFC]

The two terms:

surface_upward_mass_flux_of_carbon_dioxide_expressed_as_carbon_due_to_plant_respiration_for_biomass_growth

surface_upward_mass_flux_of_carbon_dioxide_expressed_as_carbon_due_to_plant_respiration_for_biomass_maintenance


carry the same description which makes no reference to "growth" or 
"maintenance": The surface called "surface" means the lower boundary of the 
atmosphere. "Upward" indicates a vector component which is positive when 
directed upward (negative downward). In accordance with common usage in 
geophysical disciplines, "flux" implies per unit area, called "flux density" in 
physics. The chemical formula for carbon dioxide is CO2. The phrase 
"expressed_as" is used in the construction A_expressed_as_B, where B is a 
chemical constituent of A. It means that the quantity indicated by the standard 
name is calculated solely with respect to the B contained in A, neglecting all 
other chemical constituents of A. The specification of a physical process by 
the phrase "due_to_" process means that the quantity named is a single term in 
a sum of terms which together compose the general quantity named by omitting 
the phrase. Plant respiration is the sum of respiration by parts of plants both 
above and below 
 the soil. It is assumed that all the respired carbon dioxide is emitted to the 
atmosphere. The term "plants" refers to the kingdom of plants in the modern 
classification which excludes fungi. Plants are autotrophs i.e. "producers" of 
biomass using carbon obtained from carbon dioxide.

Other relevant concepts are "mortality" (loss of biomass due to death of the 
whole plant, not only the leaves, "senescence" (loss of living biomass 
excluding plant death, e.g. leaf drop and other seasonal effects), "gross 
primary productivity" (flux from atmosphere into the plant) and "net primary 
productivity" (gross minus the amount that is respired back into the 
atmosphere).

We should add some explanation. The terms appear to relate to different 
metabolism pathways associated with the mechanisms for growth and maintenance 
(adjusting to the surroundings) in a plant. Here are some possible definitions:

  *   Maintenance respiration is defined as the carbon cost to support the 
metabolic activity of existing live tissue.
  *   Growth respiration is defined as the additional carbon cost for the 
synthesis of new growth.

Taken from 
https://escomp.github.io/ctsm-docs/doc/build/html/tech_note/Plant_Respiration/CLM50_Tech_Note_Plant_Respiration.html

It would be good to hear the views of someone who knows about these processes,

regards,
Martin


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Multiple zeros in flag_values allowed?

[Martin Juckes - UKRI STFC]

Dear Jim,


sorry, I stand corrected. Thank you for the detailed explanation.


The conformance statements looks to be in error.


Is there a clear rule for what makes a valid set of flag_values when used in 
conjunction with flag_masks?


regards,

Martin



From: Jim Biard 
Sent: 21 November 2018 20:50
To: Juckes, Martin (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Multiple zeros in flag_values allowed?


Martin,

The two subfields are independent. You can have very bad quality data and very 
bad weather at the same time. And that's how the flag masks and flag values are 
supposed to work. The mask splits off bit regions that are independent of one 
another. There is no ambiguity.

The possible options and the values masked by the flag masks of 3 (binary 0011) 
and 12 (binary 1100) are:

Weather Quality
Binary Value
Binary value & 3
Binary value & 12

very bad
very bad

0
0

very bad
bad
0001
1
0

very bad
good
0010
2
0

very bad
very good
0011
3
0

bad very bad0100
0
4

bad bad 0101
1
4

bad good0110
2
4

bad very good   0111
3
4

goodvery bad1000
0
8

goodbad 1001
1
8

goodgood1010
2
8

good
very good   1011
3
8

very good   very bad1100
0
12

very good   bad 1101
1
12

very good   good1110
2
12

very good   very good   
3
12


Grace and peace,

Jim

On 11/21/18 12:03 PM, Martin Juckes - UKRI STFC wrote:

Hello Jim, Julien,


I'm not sure .. I think the conformance might be right here and your 
flag_values should be 0,1,2,3, 4, 8,12,16, and flag_masks 3,3,3,3,28,28,28,28


If, for instance, you very_bad_quality and very_bad_weather, then "var" should 
have value 4 = '0010` in binary. Masked with 3 (1100) gives zero, and 
masked with 28 (00111000) gives 4. Re-using the zero value would make zero 
ambiguous, so you need to start the 2nd sequence at 4.


regards,

Martin


From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 20 November 2018 16:51:24
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Multiple zeros in flag_values allowed?


Julien,

That's fine. The conformance document probably needs a better statement of the 
requirement when flag masks are used.

Grace and peace,

Jim

On 11/20/18 11:40 AM, Julien Demaria wrote:
Hi,

We want to define a flags variable defining like that:
var:flag_masks = 3, 3, 3, 3, 12, 12, 12, 12 ;
var:flag_values = 0, 1, 2, 3,   0,4,  8, 12 ;
var:flag_meanings = “very_bad_quality   bad_qualitygood_quality 
   very_good_quality
very_bad_weatherbad_weather
good_weathervery_good_weather” ;

I understand from http://cfconventions.org/Conformance/conformance.html that it 
is not allowed to use several time the same value (here zero) in flag_values:

Requirements:

· The flag_values attribute values must be mutually exclusive among the 
set of flag_values attribute values defined for that variable.
So it means that for each new “bits combination” in the flags definition we 
lost one of the combination because we cannot use zero more than one time?
Do you confirm this? What is the reason?

Thanks in advance,
Julien




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu><mailto:CF-metadata@cgd.ucar.edu><mailto:CF-metadata@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
[CICS-NC] <http://www.cicsnc.org/><http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc><http://www.facebook.com/cicsnc>   
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC 
<http://cicsnc.org/><http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/><http://ncsu.edu/>
NOAA National Centers for Environmental Information 
<http://ncdc.noaa.gov/><http://ncdc.noaa.gov/>
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: 
jbi...@cicsnc.org<mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<https://www.facebook.com/NOAANCEIclimate><https://www.facebook.com/NOAANCEIclimate>
 and ocean and 
geophysics<https://www.facebook.com/NOAANCEIoceangeo

Re: [CF-metadata] Multiple zeros in flag_values allowed?

[Martin Juckes - UKRI STFC]

Hello Jim, Julien,


I'm not sure .. I think the conformance might be right here and your 
flag_values should be 0,1,2,3, 4, 8,12,16, and flag_masks 3,3,3,3,28,28,28,28


If, for instance, you very_bad_quality and very_bad_weather, then "var" should 
have value 4 = '0010` in binary. Masked with 3 (1100) gives zero, and 
masked with 28 (00111000) gives 4. Re-using the zero value would make zero 
ambiguous, so you need to start the 2nd sequence at 4.


regards,

Martin


From: CF-metadata  on behalf of Jim Biard 

Sent: 20 November 2018 16:51:24
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Multiple zeros in flag_values allowed?


Julien,

That's fine. The conformance document probably needs a better statement of the 
requirement when flag masks are used.

Grace and peace,

Jim

On 11/20/18 11:40 AM, Julien Demaria wrote:
Hi,

We want to define a flags variable defining like that:
var:flag_masks = 3, 3, 3, 3, 12, 12, 12, 12 ;
var:flag_values = 0, 1, 2, 3,   0,4,  8, 12 ;
var:flag_meanings = “very_bad_quality   bad_qualitygood_quality 
   very_good_quality
very_bad_weatherbad_weather
good_weathervery_good_weather” ;

I understand from http://cfconventions.org/Conformance/conformance.html that it 
is not allowed to use several time the same value (here zero) in flag_values:

Requirements:

· The flag_values attribute values must be mutually exclusive among the 
set of flag_values attribute values defined for that variable.
So it means that for each new “bits combination” in the flags definition we 
lost one of the combination because we cannot use zero more than one time?
Do you confirm this? What is the reason?

Thanks in advance,
Julien




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
[CICS-NC]  Visit us on
Facebook    Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC 
North Carolina State University 
NOAA National Centers for Environmental Information 
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900

Connect with us on Facebook for 
climate and ocean and 
geophysics information, and follow 
us on Twitter at @NOAANCEIclimate and 
@NOAANCEIocngeo.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Addictional area types needed for CMIP6

[Martin Juckes - UKRI STFC]

Sorry, this should have been a request for new standard region labels, not area 
types. The new regions needed are:


For continuity with CMIP5 the following names would be preferred:

  *   indian_pacific_ocean
  *   atlantic_arctic_ocean


regards,

Martin




From: Juckes, Martin (STFC,RAL,RALSP)
Sent: 05 November 2018 12:02
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Cc: Karl Taylor
Subject: Addictional area types needed for CMIP6


Hello All,


the CMIP6 data request requires some data to be provided for areas of combined 
ocean basins: (1) Indian + Pacific, and (2) Atlantic + Arctic.


For continuity with CMIP5 the following names would be preferred:

  *   indian_pacific_ocean
  *   atlantic_arctic_ocean


Can we add these area types, and are the above names appropriate?


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Decibel units in CF standard names

[Martin Juckes - UKRI STFC]

Dear David, John,


thanks for those comments.


Just to re-iterate, the current UDUNITS library does not include "dB", but it 
does include "dBZ" and some other variations which are decibels with a fixed 
specified reference value.


The 2014 UDUNITS discussion which John links to is interesting. It appears to 
have covered the ground we have covered below, and Sean Arms has just 
re-started the discussion there with a link to this thread (thanks Sean).  The 
latest proposal appears to be that a generic `dB` unit could be introduced with 
the reference level be specified in an additional attribute (yet to be defined).


The 2nd link from John is a discussion about the R package wrapper for UDUNITS, 
which does appear to have support for "dB" added, but simply defined in terms 
of the logarithm of a dimensionless number. This looks like a neat programmers 
solution which avoids having to worry about what the physical parameter is.


I've looked into this a bit further, and found that "bel" and "decibel" are 
recognised by ISO and the International Electrotechnical Commission (IEC 
60027-3:2002), along with the "neper", which is the natural logarithm of a 
ratio. A "bel" is either the log10 of the ratio for a "power" quantity or 2 
times log10 of the ratio for a "field" quantity. The IEC standard goes onto say 
that "dB" can be used to define power relative to a reference level, and 
information about reference levels should be attached to the quantity not to 
the unit -- which is in line with the current usage in 4 CF standard names.


There might be some value in trying to follow the ISO/IEC approach.


regards,

Martin



From: CF-metadata  on behalf of Moroni, David 
F (398G) 
Sent: 12 November 2018 06:24
To: John Graybeal; Jonathan Gregory
Cc: CF Metadata List
Subject: Re: [CF-metadata] Decibel units in CF standard names


John and others interested,

I was part of the initial request that dated back to 2014. Here’s the original 
GitHub ticket (still open) capturing the correspondence with the UDUNITS team: 
https://github.com/Unidata/UDUNITS-2/issues/33



I was corresponding with “mhidas” and “semmerson”, so I don’t know if these 
people are still on this project, as no further correspondence has taken place 
since July 2015. I made another attempt last year to bring some life to this 
request, but to no avail.



There was another user inquiring about representing dB as a unit, but that 
ticket has since closed and it’s not clear to me from the thread whether there 
was a positive resolution. Here’s that link: 
https://github.com/r-quantities/units/issues/176



Others on here are more than welcome to pursue this further.



Cheers,

David



From: CF-metadata  on behalf of John Graybeal 

Date: Sunday, November 11, 2018 at 9:33 PM
To: Jonathan Gregory 
Cc: CF Metadata List 
Subject: Re: [CF-metadata] Decibel units in CF standard names



Just as an aside (or maybe not), the udunits support list has been asked before 
to include dB, and I understood that they had (I think I actually saw it, but 
can’t find written confirmation). So it wouldn’t surprise me if the library 
included dB.



In case it’s useful I pasted in a bit of the old thread below.



john

---
John Graybeal
jbgrayb...@mindspring.com<mailto:jbgrayb...@mindspring.com>





On Nov 4, 2018, at 09:03, Jonathan Gregory 
mailto:j.m.greg...@reading.ac.uk>> wrote:



Dear Martin

Your points are good ones and have been raised before. More than once we have
talked about maintaining a CF version of the udunits definition to include dB
and sverdrup, or ask udunits to add them (if they're not there). dB is a dimen-
sionless unit, equivalent to 1. I suggest that dBZ should be changed to dB,
as I don't think we ought to have several of them. I believe that the default
reference levels are mostly conventional and stated in the definitions of the
standard name, as you say. They can be overridden by supplying a size-one or
scalar coordinate variable. You have previously suggested an xml table to
contain more information about the definition of standard names, haven't you?
It seems to me that an arrangement like that would be the right place to store
the default reference levels and scale factor in a machine-readable way.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> ——











Begin forwarded message:



From: "Moroni, David F (398M)" 
mailto:david.f.mor...@jpl.nasa.gov>>

Subject: Re: [CF-metadata] [cf-satellite] 
normalized_radar_backscatter_coefficient

Date: August 8, 2014 at 3:10:50 PM PDT

To: John Graybeal 
mailto:john.grayb...@marinexplore.com>>, 
"rho...@excaliburlabs.com<mailto:rho...@excaliburlabs.com>" 
mailto:rho...@excaliburlabs.com>>

Re: [CF-metadata] Turning off gitHub!!!!

[Martin Juckes - UKRI STFC]

Dear Chris, All,


yes, advising people to resign from cf-metadata to avoid messages from github 
is a bit over the top.


As an interim, I believe that the cf-metadata administrator could bar github 
from sending messages to this list (mailman offers this option on the admin 
page) until we have worked out how it should work.


regards,

Martin



From: CF-metadata  on behalf of Chris Barker 

Sent: 08 November 2018 23:04
To: CF Conventions mailing list; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Turning off gitHub

By the way, if we DO use a mailing list for a gitHub/TRAC bridge, could we 
please gve it a name other than:

cf-metadata

It's really confusing to figure out which one I should mail to.

How about cf-metadata-github-bridge or something?

-CHB


On Thu, Nov 8, 2018 at 2:51 PM, Chris Barker 
mailto:chris.bar...@noaa.gov>> wrote:
Apparently the gitHub mirroring is really driving folks crazy -- we really need 
to turn it off until it's done properly.

Action #1:

Who knows the password of the  cf-metadata-list gitHub user???

https://github.com/cf-metadata-list

That person can go log into gitHub as that user, and stop watching the Issue at 
hand -- I'm not anyone else can easily do that.

Action #2

Maybe turn off the list that's hooked up to gitHub? That would stopp all this 
'till we figure it out.

Action #3

post here, VERY CLEARLY, how folks can opt out of the gitHub mirroring list.

NOTE to CASUAL USERS:

I *think* the reason you all are having trouble opting out is that there are 
TWP cf-metadata lists:

One is the usual one, hosted by ucar:

http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

The other is hosted by llnl, and handles the gitHub (and TRAC??) email. I 
*think* everyone that subscribed to the regular list gets aauto-subscribed to 
the other list. here's a bit of info on that:

The discussions carried out on the Trac site (and now gitHub) are sent to 
subscribers of this list via messages from the majordomo list, 
cf-metad...@lists.llnl.gov. You will 
automatically be subscribed to that list. To unsubscribe, without unsubscribing 
from this list, send a message to 
"majord...@lists.llnl.gov" with "unsubscribe 
cf-metadata" in the body of your message.

-CHB
--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov



--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Decibel units in CF standard names

[Martin Juckes - UKRI STFC]

Dear Jonathan,


Interesting that your version of udunits has bel & decibel ... mine (udunits2 
which I installed on Oct. 17th) does not have these (*"udunits2: Don't 
recognize "bel"* it tells me), but does had dBz, dBW, dBV, dBv and a few 
others. There is a different udunits unit for every reference level. Do you 
know which version of udunits you are using?


cfunits, on the other hand, which uses the udunits2 library, does have bel and 
decibel added, and has them equivalent to '1'. The list of changes that cfunits 
makes relative to udunits is copied below (from the cfunits.Units help text), 
with changes that are not mentioned in the convention highlighted:


 |  ===  ==    ==
 |  Unit nameSymbol  DefinitionStatus
 |  ===  ==    ==
 |  practical_salinity_unit  psu 1e-3  New unit
 |  level1 New unit
 |  sigma_level  1 New unit
 |  layer1 New unit
 |  decibel  dB  1 New unit
 |  bel  10 dB New unit
 |  sverdrup Sv  1e6 m3 s-1Added symbol
 |  sievert  J kg-1Removed symbol
 |  ===  ==    ==


There appear to be two options: to diverge from UDUNITS in the approach taken 
for decibels, or not.

If we diverge, and use "dB" for multiple reference levels, this needs to be 
expressed more clearly in the convention.  This should include specifying 
whether "dB" is conformant with "1". Both us have some objections to this idea, 
but it may be that we need to accept that conformance of units is a fuzzy idea.

If we follow UDUNITS, I'm afraid "dB" as a unit has to go.

regards,
Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 05 November 2018 21:00
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Decibel units in CF standard names

Dear Martin

> The discussion of a machine-readable document with details of rules related 
> to specific standard names is here: https://cf-trac.llnl.gov/trac/ticket/153 
> . It has been quiet for some time. The dB issues could be covered there, as 
> you say. There is a difference in that the rules discussed in ticket 153 are 
> about specifying what needs to be in the data file, so that it is possible to 
> check that file meta-data is as complete as intended by the convention. Your 
> suggestion would entail adding information that would not be in the data file.

Yes, I agree, that's a bit different. The rules file would provide the info.
It's a convenient place to put it.

> You also suggest that alternative reference levels could be specified in an 
> attribute, but that does not appear to be allowed by current standard name 
> definitions,

I admit that I didn't check the definitions of these standard names! But there
are standard names which refer to a value with a default that can be overridden
by a coordinate variable or scalar coordinate variable (not an attribute). If
there is a use-case for different reference values for any of the dB instances
you mention, we should provide for it using that mechanism by amending the
definitions of the standard names, I suggest.

> It is true that dB is dimensionless, like "1", but we would create huge 
> confusion if dB data values were multiplied by 100 and presented as "%" ... a 
> sound_intensity_level_in_water with a value of 25% might be technically 
> equivalent to 0.25dB, but not very useful to users. I'm not sure how to deal 
> with this, but I'm not comfortable with the idea that dB is fully equivalent 
> to "1" as a unit.

I find that in my version of udunits, bel and decibel are units, and they are
not convertible to dimensionless numbers. I think that's consistent with what
you say and I agree it makes sense like that.

Best wishes

Jonathan
___
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] Addictional area types needed for CMIP6

[Martin Juckes - UKRI STFC]

Hello All,


the CMIP6 data request requires some data to be provided for areas of combined 
ocean basins: (1) Indian + Pacific, and (2) Atlantic + Arctic.


For continuity with CMIP5 the following names would be preferred:

  *   indian_pacific_ocean
  *   atlantic_arctic_ocean


Can we add these area types, and are the above names appropriate?


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Decibel units in CF standard names

[Martin Juckes - UKRI STFC]

Dear Jonathan,


The discussion of a machine-readable document with details of rules related to 
specific standard names is here: https://cf-trac.llnl.gov/trac/ticket/153 . It 
has been quiet for some time. The dB issues could be covered there, as you say. 
There is a difference in that the rules discussed in ticket 153 are about 
specifying what needs to be in the data file, so that it is possible to check 
that file meta-data is as complete as intended by the convention. Your 
suggestion would entail adding information that would not be in the data file. 
There are, however, some other issues that need tidying up.


You also suggest that alternative reference levels could be specified in an 
attribute, but that does not appear to be allowed by current standard name 
definitions, e.g. "Sound intensity is the sound energy per unit time per unit 
area. Sound intensity level in water is expressed on a logarithmic scale with 
reference to a sound intensity of 6.7e-19 W m-2. LI = 10 log10(I/I0) where LI 
is sound intensity level, I is sound intensity and I0 is the reference sound 
intensity." for sound_intensity_level_in_water states what the level is and 
does not indicate any attribute that might be used for for a different level. 
If the data provider uses a different level and encodes the information in an 
attribute of his choice it will create ambiguity, with applications tending to 
ignore the additional information and humans reading the file perhaps seeing 
it. If you believe that alternative reference levels should be possible, then 
surely we need a mechanism in the convention to specify them, and adju
 stment to descriptions such as the above to draw attention to the possibility.


It is true that dB is dimensionless, like "1", but we would create huge 
confusion if dB data values were multiplied by 100 and presented as "%" ... a 
sound_intensity_level_in_water with a value of 25% might be technically 
equivalent to 0.25dB, but not very useful to users. I'm not sure how to deal 
with this, but I'm not comfortable with the idea that dB is fully equivalent to 
"1" as a unit.


>From another perspective dB is like distance and time in that the user often 
>needs to know a reference point to make full sense of the data. For time, CF 
>supplies the additional information through the "since ..." construct (perhaps 
>qualified with an additional calendar attribute), for distance the datum can 
>be given in a grid mapping construct. For dB, CF does not currently provide a 
>place for this information.


regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 04 November 2018 17:03
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Decibel units in CF standard names

Dear Martin

Your points are good ones and have been raised before. More than once we have
talked about maintaining a CF version of the udunits definition to include dB
and sverdrup, or ask udunits to add them (if they're not there). dB is a dimen-
sionless unit, equivalent to 1. I suggest that dBZ should be changed to dB,
as I don't think we ought to have several of them. I believe that the default
reference levels are mostly conventional and stated in the definitions of the
standard name, as you say. They can be overridden by supplying a size-one or
scalar coordinate variable. You have previously suggested an xml table to
contain more information about the definition of standard names, haven't you?
It seems to me that an arrangement like that would be the right place to store
the default reference levels and scale factor in a machine-readable way.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -----

> Date: Tue, 30 Oct 2018 13:42:13 +
> From: Martin Juckes - UKRI STFC 
> To: "CF-metadata (cf-metadata@cgd.ucar.edu)" 
> Subject: [CF-metadata] Decibel units in CF standard names
>
> Hello All,
>
>
> The CF standard names have several variables using decibels ("dB") as units, 
> and one using "decibels of Z (dBZ)":
>
> sound_intensity_level_in_air1e-12 W m-2 10 log10(I/I0)
> sound_intensity_level_in_water   6.7e-19 W m-2 10 log10(I/I0)
> sound_pressure_level_in_air2e-5 Pa 20 log_10(p/p0)
> sound_pressure_level_in_water   1e-6 Pa 20 log_10(p/p0)
> equivalent_reflectivity_factor   1 mm6 m-3  10 log_10(Z/Z0)
>
>
> Each has a different reference level, and two use an additional factor two in 
> the definition of the decibel level.
>
>
> There are a few issues here, the main one is that "dB" is not a valid Udunits 
> string. There is a secondary point that the details of the definitions are 
> not easily available to software reading the files.
>
>
> Where Udunits d

Re: [CF-metadata] Using units with a scale factor

[Martin Juckes - UKRI STFC]

Hello Dave,


I am not aware of any conformance checkers which do not accommodate units of 
the form "1e3 km3", though they may exist. So we don't need to make any 
adjustments there. The use of such coordinates is consistent with current CF 
conformance document, though not with the convention itself. So there is no 
need to change anything ... but I did raise the question below as to whether we 
want to remove this discrepancy between the CF checker and the standard. It 
would be simpler, from the CMIP6 perspective, if this was not done in a hurry.

regards,
Martin


From: CF-metadata  on behalf of Dave Allured 
- NOAA Affiliate 
Sent: 02 November 2018 20:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Using units with a scale factor

Martin,

> Units of this form ["1e3 km3"] are used when the community
> requests them, usually because that is the common practice
> within their community -- they probably exist in many NetCDF
> files outside CMIP.

> Is it reasonable to refuse units which are widely used in the
> community?  I think it is worth taking some time to consider
> this, and I suggest that we allow this anomalous unit for CMIP6.

A fair question.  Please clarify.  Are you proposing to change the prohibition 
of scaled unit strings in CF section 3.1?  Or do you just want to modify one of 
the conformance checkers to accommodate the CMIP6 case alone?  I am opposed to 
the first, but the second would be okay if it was guarded by a software switch 
that is not advertised for general application.

I am concerned about backpedaling on a long standing CF restriction and 
precedent that I think is good as is.  OTOH, if there really is wide support 
for scaled unit strings, I will drop my objection.

--Dave


On Fri, Nov 2, 2018 at 3:47 AM, Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> wrote:
Dear All,

"micron" (recognised by Udunits) might be a good alternative to "um".

There is a typo in the last line of my message below -- question if whether to 
replace "1e6 km2" (not m2) with "Mm2",

regards,

Martin


From: Juckes, Martin (STFC,RAL,RALSP)
Sent: 02 November 2018 08:55

Dear Karl, Dave,

thanks, those are good suggestions.

As Karl says, 1e3 km3 is not hm3 and can't be represented with prefixes 
(Udunits does accept

As a compromise, I suggest the following changes for the CMIP6 data request:
1e-3 kg --> g
1e6 J --> MJ

and retain 1e-6 m, 1e3 km3, 1e6 km2 with a comment. For the standard names we 
can just drop the scale factor as Karl suggests.

The reason these are in there is because people were not aware of the 
restriction. As I noted below, the restriction is also omitted from the 
conformance document and from the compliance checker. Units of this form are 
used when the community requests them, usually because that is the common 
practice within their community -- they probably exist in many NetCDF files 
outside CMIP.

I believe that the statement in the convention to the effect that scale_factor 
and add_offset attributes can be used instead is misleading. These factors can 
be used, but they only affect the internal storage of the data, they to not 
modify what the user sees -- I think the truth is that packing is the only 
application of these attributes. The units attribute needs to be consistent 
with what the user sees, and will not be affected by us of a scale factor. If 
the motivation for a particular choice of units is to avoid issues with 
numerical precision by adding an offset, this underlying problem can be dealt 
with using the offset attribute, but if the choice of units has different 
motivation these attributes don't help.

This leaves us with a problem that people want to store data in units of "1e3 
km3" and we cannot express this in CF (except by "Mm km2", which looks obscure 
to me). Is it reasonable to refuse units which are widely used in the 
community? I think it is worth taking some time to consider this, and I suggest 
that we allow this anomalous unit for CMIP6.

1e-6 m and 1e6 m2 we could use "um" and "Mm2", but I think the results would be 
unsatisfactory for the users. Although the unit micro-meter is in reasonably 
common use, the ascii representation "um" is a little obscure, and "Mm" also 
looks obscure to me. I'm happy to take other views on these.

regards,

Martin


From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Dave Allured - NOAA Affiliate 
mailto:dave.allu...@noaa.gov>>
Sent: 01 November 2018 20:43

It sounds like consistency is more important than CF perfection in a particular 
use case.  In that case, I suggest continuing use of CMIP6 prescribed unit 
strings for CMIP6 purposes only, and let the CMIP6 community know of this 
inconsistency with CF 3.1.  This will probably be the least confusing for a

Re: [CF-metadata] Using units with a scale factor

[Martin Juckes - UKRI STFC]

its, e.g. "J", and consumers will need to re-scale data 
later, for some purposes.

Does anyone know why CMIP6 requested units in violation of CF 3.1?

--Dave


On Thu, Nov 1, 2018 at 10:58 AM, Taylor, Karl E. 
mailto:taylo...@llnl.gov>> wrote:
Hi Martin,

I think the main point of the relevant paragraph in section 3.1, which reads

"The Udunits syntax that allows scale factors and offsets to be applied to a 
unit is not supported by this standard. The application of any scale factors or 
offsets to data should be indicated by the scale_factor and add_offset 
attributes. Use of these attributes for data packing, which is their most 
important application, is discussed in detail in Section 8.1, "Packed 
Data"<http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#packed-data>."

is that if you want to pack the data, the proper way to do that is through 
scale_factor and add_offset, not through the scale and offset options allowed 
by udunits in the units attribute. In general I find the "scale_factor" and 
"add_offset" attributes much easier to interpret than the scale and offset 
udunits options.I would therefore:

1) continue to forbid (or strongly discourage?) use of offset and scale in the 
units attribute (and modify the conformance document to be consistent with 
this).

2)  replace the scaled units in the CMIP6 data request with units that might be 
less user friendly, but include equivalent prefix (e.g., replace  "1e6 J" with 
"MJ")

3)  replace in the standard names table all non-conforming units with 
conforming units.  I don't think the new units need to be identical to the old 
(e.g., I would replace "1e-3 kg m-2" with "kg m-2", not "g m-2").

Regarding this last point, note that the so-called "Canonical units" in the 
standard names table are there to provide guidance on what the quantity 
represents (e.g., W m-2 indicates the quantity is a flux density, not a flux).  
CF does not recommend a particular unit among all equivalent (e.g., "kg" might 
appear in the canonical units, but "g" would be just as acceptable).

Do others have opinions about this?

best regards,
Karl


On 10/29/18 7:45 AM, Martin Juckes - UKRI STFC wrote:

Hello Karl, Alison,

As part of a separate discussion on 'months since' and 'years since' in time 
units<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020648.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020648.html>,
 Klaus pointed out the use of numerical scale factors in units strings, 
although allowed by Udunits, is prohibited by the CF convention in section 3.1. 
I'm raising this here because there are 3 standard names which make use of such 
scale factors in their canonical units, and a number of CMIP6 variables. The CF 
conformance document diverges from the standard and allows any string which is 
accepted by Udunits, and hence accepts such factors. The CF checker implements 
the version according to the conformance document, as does the cf-python code 
(and hence checks on the CMIP6 variables using cf-python didn't detect this 
problem).


The CF standard names are:

integral_wrt_depth_of_product_of_sea_water_density_and_salinity  : 1e-3 kg m-2

ocean_salt_x_transport, ocean_salt_y_transport: 1e-3 kg s-1


In the CMIP6 data request, we have:

1.e6 J m-1 s-1 for atmospheric energy transport (intuadse, intvadse);

1e-3 kg m-2 for integral wrt depth of density and salinity (somint);

1e-6 m s-1 for saturated hydraulic conductivity;

1e3 km3 for sea ice volumes (sivoln, sivols);

1e6 km2 for sea ice areas (siarean, siareas, siextentn, siextents);


Should we stick to the statement in the standards document ... and bring the 
conformance document etc into line, or could the standards document be 
interpreted more loosely?


These scale factors could be replaced by prefixes, but I think there is some 
loss of legibility in some cases:

1e-3 kg --> g

1e6 J --> MJ

1e-6 m --> um

1e3 km3 --> hm3

1e6 km2 --> Mm2


(here "um" is a micrometer, "hm" a hectometer and "Mm" a megameter).


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Using units with a scale factor

[Martin Juckes - UKRI STFC]

e application of any scale factors or 
offsets to data should be indicated by the scale_factor and add_offset 
attributes. Use of these attributes for data packing, which is their most 
important application, is discussed in detail in Section 8.1, "Packed 
Data"<http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#packed-data>."

is that if you want to pack the data, the proper way to do that is through 
scale_factor and add_offset, not through the scale and offset options allowed 
by udunits in the units attribute. In general I find the "scale_factor" and 
"add_offset" attributes much easier to interpret than the scale and offset 
udunits options.I would therefore:

1) continue to forbid (or strongly discourage?) use of offset and scale in the 
units attribute (and modify the conformance document to be consistent with 
this).

2)  replace the scaled units in the CMIP6 data request with units that might be 
less user friendly, but include equivalent prefix (e.g., replace  "1e6 J" with 
"MJ")

3)  replace in the standard names table all non-conforming units with 
conforming units.  I don't think the new units need to be identical to the old 
(e.g., I would replace "1e-3 kg m-2" with "kg m-2", not "g m-2").

Regarding this last point, note that the so-called "Canonical units" in the 
standard names table are there to provide guidance on what the quantity 
represents (e.g., W m-2 indicates the quantity is a flux density, not a flux).  
CF does not recommend a particular unit among all equivalent (e.g., "kg" might 
appear in the canonical units, but "g" would be just as acceptable).

Do others have opinions about this?

best regards,
Karl


On 10/29/18 7:45 AM, Martin Juckes - UKRI STFC wrote:

Hello Karl, Alison,

As part of a separate discussion on 'months since' and 'years since' in time 
units<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020648.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020648.html>,
 Klaus pointed out the use of numerical scale factors in units strings, 
although allowed by Udunits, is prohibited by the CF convention in section 3.1. 
I'm raising this here because there are 3 standard names which make use of such 
scale factors in their canonical units, and a number of CMIP6 variables. The CF 
conformance document diverges from the standard and allows any string which is 
accepted by Udunits, and hence accepts such factors. The CF checker implements 
the version according to the conformance document, as does the cf-python code 
(and hence checks on the CMIP6 variables using cf-python didn't detect this 
problem).


The CF standard names are:

integral_wrt_depth_of_product_of_sea_water_density_and_salinity  : 1e-3 kg m-2

ocean_salt_x_transport, ocean_salt_y_transport: 1e-3 kg s-1


In the CMIP6 data request, we have:

1.e6 J m-1 s-1 for atmospheric energy transport (intuadse, intvadse);

1e-3 kg m-2 for integral wrt depth of density and salinity (somint);

1e-6 m s-1 for saturated hydraulic conductivity;

1e3 km3 for sea ice volumes (sivoln, sivols);

1e6 km2 for sea ice areas (siarean, siareas, siextentn, siextents);


Should we stick to the statement in the standards document ... and bring the 
conformance document etc into line, or could the standards document be 
interpreted more loosely?


These scale factors could be replaced by prefixes, but I think there is some 
loss of legibility in some cases:

1e-3 kg --> g

1e6 J --> MJ

1e-6 m --> um

1e3 km3 --> hm3

1e6 km2 --> Mm2


(here "um" is a micrometer, "hm" a hectometer and "Mm" a megameter).


regards,

Martin
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 'years since' time units

[Martin Juckes - UKRI STFC]

Hi Ethan,


Yes, I may have mis-interpreted that section of the convention, so I'd be in 
favour of clearing it up.


We might start by saying that the *units string* (the value of the units 
attribute) takes the form " [since ]" where the optional 
"since " component is only allowed for units of time, and the units 
element is to be interpreted following the Udunits definitions of units (apart 
from listed exceptions).


A clearly stated distinction between "units string" and "units" would help 
here. Do you agree that the intention is that the "units" should not just have 
a format as specified by Udunits, but should also have the meaning as specified 
by Udunits (in many cases this is a meaning inherited from SI), while the 
timestamp is merely using the Udunits format (which might be better described 
as the ISO 8601 format)?


Udunits is used both by the CF checker and by cf-python for validating units, 
but I think cf-python does the calendar conversions separately.


The fact that validation of units relies on Udunits has masked the problem of 
standard names being introduced with canonical units which are passed by 
Udunits not fully compliant with the convention (see 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020650.html ).


regards,

Martin


From: CF-metadata  on behalf of Ethan Davis 

Sent: 30 October 2018 22:07:04
To: CF metadata
Subject: Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 
'years since' time units

Hi all,

CF specifies that the value of the units attribute is a string that can be 
recognized by UDUNITS. (There are a few variations, e.g., “as per the 
recommendations [in UDUNITS]” and “formatted as per the udunits.data file”.) 
While there are a few recommendations based on how UDUNITS handles or 
interprets particular units strings, there is no mention in CF that UDUNITS 
must or even should be used for anything beyond validating a units string.

[Sorry, I haven’t really kept up with the “Add calendars gregorian_tai ...” 
conversation. But I see now that Chris mentions the above [1]. Hopefully, I 
haven’t missed too much else in my skimming of that conversation.]

It seems that CF should be more explicit about how it relies on UDUNITS? Beyond 
recognizing valid units strings, is UDUNITS a reference implementation for how 
units should be interpreted and values converted. If so and given that UDUNITS 
does not handle calendars, it seems clear that time (at least when a calendar 
is specified?) should be an exception. Are there other areas that should be 
exceptions?

Cheers,

Ethan

[1] 
https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-434369818

On Mon, Oct 29, 2018 at 7:48 AM Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> wrote:
Hello Klaus,

you are right, "30 days" would be invalid according the penultimate paragraph 
of section 3.1  it would, however, be OK according to the rules in the 
conformance document and the CF checker. There are 3 current standard names 
which have invalid canonical units by this rule (of the form "1e-3 kg ..."), 
and several CMIP6 variables. It is a distraction from the main topic here ... 
so I'll start another thread.

I agree with your suggestion that many issues could be resolved by adding new 
units to the "udunits2-common.xml" section of the UDUNITS database. If we want 
to support statements of the form "units = calendar_months since 1900-01-01", a 
little more work would be needed. The "... since ..." format is supported by 
UDUNITS for time and the date is always interpreted in terms of the 
Julian/Gregorian calendar: getting it extended to a new family of units may be 
difficult.

regards,
Martin

From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Klaus Zimmermann 
mailto:klaus.zimmerm...@smhi.se>>
Sent: 29 October 2018 12:27
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 
'years since' time units

Hello All,

all in all it seems that there is broad agreement that we need a new way
to describe coarser time information that has to be separate from the
time domain as described in udunits and, by extension, CF up to now.

The finest unit there should be a general calendar month, the only other
one that was mentioned up to now would be some form of calendar year
that always consists of 12 calendar months.

The relationship to day of year or day of month will depend on external
choices like the calendar and application, but might even be ill defined
if, for example, in a climatology data from different calendars is combined.
Consequently, no automatic conversion between the new domain and the
regular time domain is possible.


The open question really is how this should

[CF-metadata] Decibel units in CF standard names

[Martin Juckes - UKRI STFC]

Hello All,


The CF standard names have several variables using decibels ("dB") as units, 
and one using "decibels of Z (dBZ)":

sound_intensity_level_in_air1e-12 W m-2 10 log10(I/I0)
sound_intensity_level_in_water   6.7e-19 W m-2 10 log10(I/I0)
sound_pressure_level_in_air2e-5 Pa 20 log_10(p/p0)
sound_pressure_level_in_water   1e-6 Pa 20 log_10(p/p0)
equivalent_reflectivity_factor   1 mm6 m-3  10 log_10(Z/Z0)


Each has a different reference level, and two use an additional factor two in 
the definition of the decibel level.


There are a few issues here, the main one is that "dB" is not a valid Udunits 
string. There is a secondary point that the details of the definitions are not 
easily available to software reading the files.


Where Udunits does support decibels, it is units such as dBZ, dBW for which a 
specific reference value is defined. As all these variables have different 
reference values, that would require 4 new units.


The reference values are currently specified within the standard name 
description. It maattry make sense to add explicit attributes so that this 
information can be made more accessible to users and software reading the file. 
E.g. "decibel_reference_level" with the name of a scalar variable holding the 
reference value (specifying standard name, units and value) and 
"decibel_scale_factor" set to "10" or "20". With these modifications it would 
be possible to compute the power/intensity etc from the decibel parameter.


regards,

Martin

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Using units with a scale factor

[Martin Juckes - UKRI STFC]

Hello Karl, Alison,


As part of a separate discussion on 'months since' and 'years since' in time 
units, 
Klaus pointed out the use of numerical scale factors in units strings, although 
allowed by Udunits, is prohibited by the CF convention in section 3.1. I'm 
raising this here because there are 3 standard names which make use of such 
scale factors in their canonical units, and a number of CMIP6 variables. The CF 
conformance document diverges from the standard and allows any string which is 
accepted by Udunits, and hence accepts such factors. The CF checker implements 
the version according to the conformance document, as does the cf-python code 
(and hence checks on the CMIP6 variables using cf-python didn't detect this 
problem).


The CF standard names are:

integral_wrt_depth_of_product_of_sea_water_density_and_salinity  : 1e-3 kg m-2

ocean_salt_x_transport, ocean_salt_y_transport: 1e-3 kg s-1


In the CMIP6 data request, we have:

1.e6 J m-1 s-1 for atmospheric energy transport (intuadse, intvadse);

1e-3 kg m-2 for integral wrt depth of density and salinity (somint);

1e-6 m s-1 for saturated hydraulic conductivity;

1e3 km3 for sea ice volumes (sivoln, sivols);

1e6 km2 for sea ice areas (siarean, siareas, siextentn, siextents);


Should we stick to the statement in the standards document ... and bring the 
conformance document etc into line, or could the standards document be 
interpreted more loosely?


These scale factors could be replaced by prefixes, but I think there is some 
loss of legibility in some cases:

1e-3 kg --> g

1e6 J --> MJ

1e-6 m --> um

1e3 km3 --> hm3

1e6 km2 --> Mm2


(here "um" is a micrometer, "hm" a hectometer and "Mm" a megameter).


regards,

Martin


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 'years since' time units

[Martin Juckes - UKRI STFC]

Hello Klaus,

you are right, "30 days" would be invalid according the penultimate paragraph 
of section 3.1  it would, however, be OK according to the rules in the 
conformance document and the CF checker. There are 3 current standard names 
which have invalid canonical units by this rule (of the form "1e-3 kg ..."), 
and several CMIP6 variables. It is a distraction from the main topic here ... 
so I'll start another thread.

I agree with your suggestion that many issues could be resolved by adding new 
units to the "udunits2-common.xml" section of the UDUNITS database. If we want 
to support statements of the form "units = calendar_months since 1900-01-01", a 
little more work would be needed. The "... since ..." format is supported by 
UDUNITS for time and the date is always interpreted in terms of the 
Julian/Gregorian calendar: getting it extended to a new family of units may be 
difficult.

regards,
Martin

From: CF-metadata  on behalf of Klaus 
Zimmermann 
Sent: 29 October 2018 12:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 
'years since' time units

Hello All,

all in all it seems that there is broad agreement that we need a new way
to describe coarser time information that has to be separate from the
time domain as described in udunits and, by extension, CF up to now.

The finest unit there should be a general calendar month, the only other
one that was mentioned up to now would be some form of calendar year
that always consists of 12 calendar months.

The relationship to day of year or day of month will depend on external
choices like the calendar and application, but might even be ill defined
if, for example, in a climatology data from different calendars is combined.
Consequently, no automatic conversion between the new domain and the
regular time domain is possible.


The open question really is how this should be implemented. It could be
brought into the udunits database, coded completely separately in an
attribute other than units, or written in the units attribute, but in a
special form to mark it as separate from udunits.

Once these choices are made, some names need to be agreed.


I want to add some technical remarks. Using "units: 30 days" as proposed
by Martin would be in violation of CF 3.1 (as I understand it), where it
says that scale factors as supported by udunits are not allowed in CF.
Of course, this could be changed and indeed CF seems to be lagging
behind the current udunits a bit: udunits2 supports ppm, for instance,
and does not contain a udunits.dat file anymore.

Instead, the database of units is distributed as a set of XML files,
namely "udunits2.xml" (that merely imports the others),
"udunits2-base.xml" (that contains the SI base units),
"udunits2-derived.xml" (that contains the SI derived units),
"udunits2-prefixes.xml" (that contains the SI prefixes, of course). All
of the data up to this point comes from the SI governing body, but there
is one last file, "udunits2-common.xml", that contains a rich set of
definitions that were deemed useful despite not being officially
endorsed by the SI, among them ppm.

It seems quite possible to include the new domain into the -common file;
alternatively one could think to distribute an extension or an extended
version of the udunits database, while still relying on the udunits
library for parsing and conversion of all units.

I personally would prefer to either include the new definitions in
udunits or have them as a completely separate attribute, but not to mix
a new way of interpretation into the currently udunits only units attribute.

Regards
Klaus


On 29/10/18 11:12, Martin Juckes - UKRI STFC wrote:
> Hello All,
>
>
> There is perhaps a simpler alternative to deal with the problem of encoding 
> data from 360 day calendars: the data described by Ryan should be encoded 
> with "units: 30 days", which would be valid and accurate.
>
>
> The references to UDUNITS may be a bit of a distraction ... UDUNITS inherits 
> all its definitions of units of time, distance, mass, heat and current from 
> the SI units. Coincidentally, the governing body for SI units will be 
> discussing a change in the definition of the kilogram this month (it is to be 
> redefined in terms of he Planck constant). What is happening to the SI kg is 
> a bit of a diversion, but I want to make the point that the relationship 
> between, for instance, energy, mass, length and time, and the way in which 
> that is represented in our units system is fundamental to our understanding 
> of many aspects of the physical world. Making a change to the interpretation 
> of "time" which destroys this relationship would be a serious step.
>
>
> The CDM library that Dave referred to 

Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 'years since' time units

[Martin Juckes - UKRI STFC]

its in 
all possible calendars), the original problem will be forgotten. Given my lack 
of experience in this field, it is hard for me to tell whether the solutions 
being proposed here will actually impact the original issue. I cannot force the 
data provider in question (IRI data library) to re-encode all its data with a 
new convention. If I could, I would just have them re-encode following the 
existing standard and be done.

In any case, thank you all very much for this important work. I sincerely 
appreciate all of your efforts.

Best,
Ryan



On Fri, Oct 26, 2018 at 11:48 AM Martin Juckes - UKRI STFC 
mailto:martin.juc...@stfc.ac.uk>> wrote:
Dear All,


My apologies to Dave for creating the diversion around the opaqueness of 
UDUNITS. There are two sides to this otherness: on the one hand, it is an 
independent group of people doing good work that we can take advantage of, on 
the other, they express the rules and concepts which they arrive at in their 
own syntax which takes an effort for us to disentangle.


Before proposing anything to UDUNITS (if we decide to go that way) I think it 
is worth thinking a bit more about exactly what we want and how it fits into 
other frameworks for managing units. Dave has already mentioned some software 
frameworks which deal with this cleanly, but Lars has pointed out that we need 
an extra step to get something in the standard.


UDUNITS ties itself back to the SI standard, which is clearly anchored in 
physical constants and is not going to touch this sort of thing. UDUNITS does 
have some units which are not defined in terms of SI units ... but they mainly 
have a fairly direct linear relationship with SI units.


The GML (Geography Markup Language) has some potentially relevant formalisms. 
They have a concept of "ConventionalUnits", which are units which are not 
defined in terms of SI units (though they may have a rough conversion factor).  
They also have "AbstractTime" constructions which support the calendar year and 
months. In the GMLJP2 application profile for JPEG the "AbstractTime" concept 
is implemented for 3 calendars (Gregorian, Julian and GPS).


Jim has suggested "coarse_time/year/month" and "orbital_time/year/month" as 
alternative labels. The 2nd of these made me think about the option of just 
counting orbits, which is already supported by the UDUNITS unit of "cycle", 
which is a measure of angle. Unfortunately this wouldn't work as the calendar 
year and month not a fixed angular displacements around the sun. One of the 
main motivations is to have a variable which is explicitly defined to follow 
the rules set out by various calendars, so perhaps "calendar_time" would be 
better (as a standard name)? Used together with "calendar_month" and 
"calendar_year", this would take us back to Karl's suggestion on the 18th.


As Jim has said, if we introduce these new units in association with a new 
standard name, we can make it clear that they do not transform directly into 
the existing time units (though software should be able to this easily enough). 
Karl has suggested that the reference time should also be restricted to monthly 
granularity, e.g. "calendar_months since 2001-01".


As Karl has said, the big gain will be in making it easy for people to describe 
simple concepts (such as data for each calendar month) without having to work 
their way around the fact that the UDUNITS month is a fixed number of seconds.


Jonathan has suggested that we should rely on software to do the conversion 
from the simple view of calendar months into CF metadata and back, but that 
will result in multiple different implementations presenting the users with a 
range of options. On the basis that simple information should be stored 
transparently, I think we should try to accommodate the many users who want 
calendar months directly. This would also make it possible to specify an 
alternative, slightly more transparent, formulation for cell_methods for 
monthly climatological means: rather than "time: mean within days time: mean 
over days time:mean over years" we could have "calendar_time: mean within 
calendar_month calendar_time:mean over calendar_year".


We have all been talking as if the length of the day is a fixed number of 
seconds  which is a good enough approximation, but looking up the 
definition of "GPS time" has reminded me that this isn't the case. Some days 
have leap-seconds, most don't (there is about 1 leap second every 1.5 years). 
We don't have to worry about this in climate applications, but there may be 
Earth Observation applications that need to be careful about these leap 
seconds. This was discussed on the CF list back in 2015, and the conclusion was 
that there was no need to take it into account, as the impact would be 
negligible for the use cases we want to support. On the other han

Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 'years since' time units

[Martin Juckes - UKRI STFC]

alendar_year 
and calendar_month (=calendar_year/12) and also calendar_week and calendar_day 
(=calendar_week/7) as units of a calendar system which may involve irregular 
time increments. The calendar_day differs from the day when a leap second is 
introduced, once every 1.5 years on average. The calendar_month is a whole 
number of days, and never equivalent to the month time unit. These are not 
physical based units, but they are widely used in societal and environmental 
applications.


I'm sorry that this has turned into a rather disjointed set of ideas  
should we start an trac ticket?


regards,

Martin


From: Lowry, Roy K. 
Sent: 26 October 2018 09:46
To: David Blodgett; Juckes, Martin (STFC,RAL,RALSP)
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 
'years since' time units


Dear Dave,


I see no problem with CF incorporating external standards such as UDUNITS 
providing that standard is adequately maintained (e.g. addition of new 
concepts) and supported by its governance through the provision of tools. In my 
opinion UDUNITS governance makes the grade. Indeed, it was a tool development 
query by UDUNITS that kicked off this thread and Martin's suggestion is to 
contact UDUNITS governance which I'm sure won't be ignored.


The alternative would be for CF to set up its own controlled vocabulary for 
units of measure. Even if the resources to do this could be secured I feel it 
would be a terrible waste.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of David 
Blodgett 
Sent: 26 October 2018 01:31
To: Martin Juckes - UKRI STFC
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 
'years since' time units

Dear Martin,

I'll leave it to others to argue the merits of various solutions. My aim was to 
point out that this problem is solved by prominent software which does 
basically what you describe. We could quibble about the concept of time and 
date being different, but given that this problem has a clear solution, I don't 
really care to. One way or another we will need to introduce the complexity of 
an additional way of discretizing a temporal axis that is based on cyclic 
calendar days/months/years rather than continuous seconds increments of time 
that add up to days months and years in nuanced ways depending on the time of 
year or leap-cycle.

Your suggested path -- work with the UDUNITS community to define this new type 
of timeline unit -- make very good sense.

I would like to clarify my point about UDUNITS being relied on. The parallel 
would be reliance on EPSG codes for projection parameters. A UDUNITS string is 
completely opaque to software that ONLY knows CF. By my understanding of CF, 
this breaks the rules by not fully describing the concept within the 
specification. I'm not complaining, I think it was the right decision to use an 
external source for units of measure -- I'm just pointing out the inconsistency 
relative to other aspects of the specification.

- Dave

> On Oct 25, 2018, at 7:37 AM, Martin Juckes - UKRI STFC 
>  wrote:
>
> Dear David, Lars,
>
>
> I'm afraid I do have a couple of reservations, though I understand the 
> motivation for trying to support this kind of information in the convention.
>
>
> My main concern is that "time" is a very important concept and it is distinct 
> from "date". Time has a very precise meaning which is recognised across 
> scientific domains. I recognise that it may be used interchangeably with 
> "date" in many contexts, but the CF convention is built on precisely defined 
> terms, so I feel it would be counter-productive to broaden our concept of 
> "time" to include "date". On the other hand, introducing a new CF name of 
> "date"  would make it possible to introduce the sort of information that you 
> are talking about.
>
>
> My 2nd concern is the suggestion that we should relax the current 
> specification of "units", which allows the comprehensive UDUNITS package to 
> be used when comparing variables without different units. I'm puzzled by your 
> suggestion the UDUNITS is opaque ... it looks like a pretty well maintained 
> library to me. Their definition of "year" as a "tropicalyear" agrees with the 
> GNU units library. I can't see why the information you want has to go in the 
> "units" attribute (I'm sorry if I have missed your explanation on this 
> point). There are two alternatives which I would prefer:
>
>
> (1) try to persuade UDUNITS to accept calendar_year and calendar_month as 
> units of "date", or perhaps "calendar_time"

Re: [CF-metadata] ice_sheet/land_ice confusion

[Martin Juckes - UKRI STFC]

t to mistake them for one 
another. We have sometimes taken a similar approach with standard names, e.g. 
joining process names with more than one _and_, when we have needed to be very 
clear about what is included/excluded in a particular term.

 In his most recent post, Martin wrote:
>Firstly, I think lake_and_sea_ice should be aliassed to  
>fresh_water_and_sea_ice, or have a change of definition to exclude river ice).
Because of my suggestions above, we'd have to go with the option of clarifying 
the definition to exclude river_ice. I think it makes sense to regard lake_ice 
as part of freshwater ice and it's preferable to implying that 'fresh water' 
only means lakes.

Karl pointed out that with the introduction of the new area_types we need to 
provide a definition of ice_free_land (currently it doesn't have one). Karl 
wrote:
> I suggest we also provide some text guidance as to what ice_free_land 
> includes. I think it should probably be the complement of land_ice, but one 
> could argue that it should be the complement of ice_and_snow_on_land. In 
> either case we need to make this
> clear in the CF area type listing. I would note that ice_free_land as a type 
> has not been used in CMIP5 or CMIP6 and in addition it is not used in any of 
> the current standard_names.

To take the last point first, ice_free_land was in fact proposed by Jonathan in 
2011: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/003998.html. It was 
proposed in conjunction with standard names for modelling ice-sheet mass 
balance,
surface_snow_and_ice_melt_flux, surface_snow_and_ice_refreezing_flux and 
land_ice_surface_specific_mass_balance_flux. We didn't discuss exactly what 
ice_free_land should mean. That wasn't an omission, it's simply that we didn't 
have definitions for area types at that time - it's only as we have added to 
the list that it has become necessary to manage them in a more careful way. 
However, it's clear that the only other relevant entry in the area_types table 
at the time was land_ice, so Karl's first interpretation is correct: 
ice_free_land and land_ice are the complements of one another. I think the 
standard names proposed at the same time also suggest that only snow overlying 
ice was under consideration, not snow on ground or vegetation. I suggest that 
we add the following description of ice_free_land:
'The area_type ice_free_land is the complement of the area_type land_ice, i.e. 
it indicates areas where glaciers, ice-caps, grounded ice sheets resting on 
bedrock and floating ice-shelves do not occur.'
For further clarity I suggest we also add a sentence to the definition of 
land_ice:
' "Land ice" means glaciers, ice-caps, grounded ice sheets resting on bedrock 
and floating ice-shelves. The area_type land_ice is the complement of the 
area_type ice_free_land.'

Karl has also asked how we should interpret standard names that say 'land_ice', 
i.e., we know what *area* they cover, but do (at least some of them) also 
include the overlying snow? This question affects names such as 
tendency_of_change_in_land_ice_amount - does it include the mass of the snow 
plus ice, or strictly the ice? These questions haven't arisen before in this 
level of detail, not least because some of the names have been around for a 
long time. I agree that it would be useful to clarify the standard name 
definitions wherever possible.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Martin Juckes 
- UKRI STFC
Sent: 22 October 2018 13:13
To: Jonathan Gregory ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] ice_sheet/land_ice confusion

Dear Jonathan,


Thanks ... that is very clear, but it looks as though I haven't expressed my 
view clearly enough yet: I don't agree that snow is a specific form of ice.


In the atmosphere everything is reasonably clear, and I do agree that, within 
the atmospheric context, snow is just a form of ice. However, things get more 
complicated when the snow hits the ground and piles up.


In glaciology people talk about the transitions from snow through névé and firn 
and finally into ice. This transition is also of importance in the study of 
sea-ice. I'm not an expert in this area, but it is clear that there is an 
extensive community of people who see "snow" and "ice" as distinct. In the 
glaciological context we could make things unambiguous by referring to a 
transition from firn to "glacial ice", but that would not work in the sea-ice 
context, where we have exactly the same transition. A term such as "solid_ice" 
might work (solidity appears to be the main criteria for the transition, e.g. 
expressed in terms of the connectivit

Re: [CF-metadata] ice_sheet/land_ice confusion

[Martin Juckes - UKRI STFC]

e mechanism for the formation of the areal coverage.


I think it will be clearer overall if we don't treat surface snow as a 
sub-category of surface ice: it just conflicts too much with common usage and 
usage in the relevant scientific communities.


Firstly, I think lake_and_sea_ice should be aliassed to  
fresh_water_and_sea_ice, or have a change of definition to exclude river ice);

We could follow the same pattern for "ice_on_land", and replace it with 
"fresh_water_and_land_ice", but that approach does not extend well to the snow 
and ice case.


How about:

  ice_and_snow_on_land -> land_surface_ice_and_snow (as you suggested);
  ice_on_land -> land_surface_ice  (omitting the "except snow");

regards,
Martin





From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 19 October 2018 13:21
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] ice_sheet/land_ice confusion

Dear Martin

I agree that snow is a specific form of ice, and that we have and need many
standard names which refer to it. I'm questioning only the need for the area
type of ice_on_land, because I'm wondering in which circumstances one needs to
consider the area occupied by all conceivable forms of frozen water with the
sole exception of snow.

However, the reason for starting this thread was a concern that land_ice is
confusingly similar to ice_on_land. I tried to combine these concerns by
suggesting making ice_on_land an alias of ice_and_snow_on_land. If we need to
keep them distinct, we could alias ice_on_land as ice_on_land_except_snow,
to be clear what it means, and less easily confused with land_ice.

Perhaps even better, to be consistent with the many standard_names that use
the phrase surface_snow, could we change both
  ice_and_snow_on_land -> land_surface_ice_and_snow
  ice_on_land -> land_surface_ice_except_snow
There is one existing standard name which contains the phrase surface_ice, by
analogy with surface_snow. However, its definition does not state whether it
includes snow or not! Hence for consistency I think we ought to clarify this
standard name as well: to tendency_of_atmosphere_mass_content_of_water_vapor_
due_to_sublimation_of_surface_ice we should append ether _and_snow, or
_except_snow, according to what it is intended to include.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Fri, 19 Oct 2018 09:53:59 +
> From: Martin Juckes - UKRI STFC 
> To: "Taylor, Karl E." , "cf-metadata@cgd.ucar.edu"
>, Jonathan Gregory
>
> Subject: Re: [CF-metadata] ice_sheet/land_ice confusion
>
> Dear Karl, Jonathan,
>
>
> I appreciate where you are coming from with the assertions that snow is a 
> form of ice, but it ain't necessarily so, at least not in the current CF 
> names list. Karl has made the point that there are multiple issues to 
> consider when comparing usage in area types with usage in standard names, but 
> it is surely important to be consistent at this level, and decide whether we 
> want to deprecate all the names that treat ice and snow as distinct (some of 
> them agreed quite recently).
>
>
> As far as CMIP6 is concerned, the land-ice modellers (which means modellers 
> of ice sheets and shelves, as glaciers and ice caps don't yet figure in the 
> active realms of CMIP models) do not appear to care much about the 
> distinction between ice and snow ... once it has touched the ground it adds 
> to the mass of the ice and that is all you need to know (apart from perhaps 
> albedo modelling). For sea-ice, on the other hand, there will be diagnostics 
> representing the transition from snow to ice, clearly implying that snow is 
> "distinct" from "ice" in this context.
>
>
> In LS3MIP also has an understanding of "snow" which conflicts with the simple 
> idea that "snow is ice". For this community, "snow" is a matrix of ice 
> crystals, air and liquid water which lies on the ground.
>
>
> I appreciate that these issues are somewhat tangential to the specific 
> discussion here, but adopting the rule that "snow is ice" does have 
> consequences beyond the present discussion, and it would be a significant 
> change from the status quo. This goes beyond the use of area types in 
> standard names: the question is whether we are using the concepts of "snow" 
> and "ice" consistently.
>
>
> It is clear, I think, that the distinction between solid ice and the matrix 
> of ice, air an liquid commonly known as "snow", or perhaps "snow-pack", is 
> important in a range of land and sea-ice surface modelling contexts -- 
> including for some CMIP6 diagnostics. That doesn't change the fact that we 
> appear to have 

Re: [CF-metadata] ice_sheet/land_ice confusion

[Martin Juckes - UKRI STFC]

nt is 
unneeded if we limit th
 e use of land_ice to identifying a surface type in cell_methods or as a value 
allowed for variables with the standard_name=area_type (because in those cases 
it is irrelevant whether the "solid ice" is or is not covered by snow).]

best regards,
Karl


On 10/18/18 10:18 AM, Martin Juckes - UKRI STFC wrote:

Dear Alison, Jonathan,


we do need to be careful about the distinction between snow and ice.


The generally reliable AMS glossary is not much help here: 
*firn<http://glossary.ametsoc.org/wiki/Firn><http://glossary.ametsoc.org/wiki/Firn>"
 is part of the process of transformation from 
*snow<http://glossary.ametsoc.org/wiki/Snow><http://glossary.ametsoc.org/wiki/Snow>*
 to *land ice* , *land 
ice<http://glossary.ametsoc.org/wiki/Land_ice><http://glossary.ametsoc.org/wiki/Land_ice>*
 is a layer of *ice* formed on land and 
*ice<http://glossary.ametsoc.org/wiki/Ice><http://glossary.ametsoc.org/wiki/Ice>*
 includes snow, which leaves the definition of "firn" a bit wanting.


For the glaciologists, the transformation snow --> firn --> ice appears to be 
well established, but there are other usages in which ice includes snow. In 
cloud physics it seems to be clear that snow flakes are ice crystals.


regards,

Martin



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jonathan Gregory 
<mailto:j.m.greg...@reading.ac.uk>
Sent: 18 October 2018 14:52
To: Pamment, Alison (STFC,RAL,RALSP)
Cc: CF-metadata (cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>)
Subject: Re: [CF-metadata] ice_sheet/land_ice confusion

Dear Alison

Yes, I realise I'm being a bit provocative and perhaps rash in trying to get
rid of ice_on_land (because I think it's terribly confusing). Distinctions can
be made for practical purposes (e.g. in models) between ice and snow, although
in reality it's a continuum. I'm wondering who has a need for an area type
including *all* kinds of frozen water on land (ice sheets, glaciers, firn/neve,
rivers, lakes, ponds, frozen flood water, snowfall which has melted and
refrozen as ice, hailstones, frost) *except* snow - and if so, how do they
distinguish snow from the rest.

Best wishes

Jonathan

On Thu, Oct 18, 2018 at 12:29:01PM +, Alison Pamment - UKRI STFC wrote:


Date: Thu, 18 Oct 2018 12:29:01 +
From: Alison Pamment - UKRI STFC 
<mailto:alison.pamm...@stfc.ac.uk>
To: "CF-metadata (cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>)" 
<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] ice_sheet/land_ice confusion

Dear Jonathan and Karl,

I agree with Karl's suggestion to change "lying snow" to "surface snow" in the 
definitions of ice_on_land and ice_and_snow_on_land. That would be more 
consistent with standard names and their definitions.

We seem to agree also that changes to area_type strings should be treated in 
the same way as changes to standard_names, i.e. using aliases. There is no 
formal description of the area_type table in the Conventions document. The XML 
schema would look very much like that of the standard name table, minus the 
units and the amip and grib tags. In fact, I think it has been agreed in 
principle to remove the AMIP and GRIB columns from the standard name table 
itself (CF trac #116). I will submit a GitHub issue to encompass trac #116 and 
some proper documentation of the area_type table. The CF-checker would need to 
cope with the possibility of aliases for area_types, so it probably needs to go 
in the conformance document too.

Regarding Jonathan's assertion that "snow *is* ice", once again I am a little 
cautious. We certainly have standard names that *don't* regard them as being 
the same thing. For example, the two names I mentioned previously: 
change_over_time_in_amount_of_ice_and_snow_on_land and 
change_over_time_in_thermal_energy_content_of_ice_and_snow_on_land. I was under 
the impression that models treat ice and freshly fallen snow as different 
variables which sometimes co-exist in the same grid cell and sometimes don't.  
I haven't yet managed to track it down in the mailing list archives, but I also 
have a vague recollection of a discussion some years ago about the surface 
albedo being affected by factors such as the age of ice and snow, which would 
be important when considering an area_type. Perhaps I'm wrong about the last 
point, so I'd be interested to know what others think about the suggestion to 
turn  ice_on_land into an alias of ice_and_snow_on_land.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: 
alison.pamm...@stfc.ac.uk<mailto:alison.pamm...@stfc.ac.uk>
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
F

Re: [CF-metadata] 'months since' and 'years since' time units

[Martin Juckes - UKRI STFC]

Dear Jonathan,


I think you could go further and disallow the use of "month" or "year" as a 
time unit when the calendar is not standard.


If the "ncdump -t" option produces what the user expects when he has units  
"months since 1900-01-01" and a 360 day calendar, then it is going to be 
inconsistent with the current convention.


I still feel that there is an argument for enabling the storage of information 
in user months in the files. E.g. I wish to compare monthly mean data from 20 
climate models which use a range of different calendars. The mean across the 
models is not on any specific calendar ... I could pretend it is and use units 
of "days since ...", but the mappings from input time coordinates to output 
time coordinates then become rather complex, when they should be trivial. 
Having a "date" standard name which allowed the input data to have a 
"calendar_month" coordinate would solve this (and I think Klaus's suggestion 
would also solve it),


regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 18 October 2018 17:10:46
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] 'months since' and 'years since' time units

Dear all

This is an interesting discussion, and I agree that's a tricky subject. If only
we could have a well-behaved Earth which orbited the sun in an integral and
easily factorisable number of days!

So far I still think that we should not change the way we interpret the units
string. It's in udunits format, and should be interpreted according to the
calendar attribute. I would suggest that it's helpful to regard time coords as
*encoded* and not necessarily easy for humans to read. It's certainly nice to
see "time=1, 2, 3, ..." months since a reference date - that is easy to read -
but when you get to 747 or 4689 months since a reference date, you don't know
what it means any more (unless you're extremely good at mental arithmetic), and
you might as well encode it as days.

The antidote to inconvenient encoding is convenient software. For example,
could cftime allow the user to construct a time coordinate variable with a
spacing of calendar months, but encode it in the netCDF file in days? Then it's
transparent. Similarly, time coordinate variables can be decoded into human-
readable strings by calendar-aware software. It seems to me that this isn't
different in principle from using ncdump to read a netCDF file, rather than
insisting it should be intelligible when read in hexadecimal. In fact, ncdump
itself has a -t option, which should help, according to the man page:

"-t controls display of time data, if stored in a variable that uses a udunits
compliant time representation such as `days since 1970-01-01' or `seconds since
2009-03-15 12:01:17'  If this option is specified, time data values are
displayed as human-readable date-time strings rather than numerical values,
interpreted in terms of a `calendar' variable attribute, if specified. ...
Calendar attribute values interpreted with this option include the CF
Conventions values `gregorian' or `standard', `proleptic_gregorian', `noleap'
or `365_day', `all_leap' or `366_day', `360_day', and `julian'."

I agree with comments that if we introduced new units such as calendar_month
or 30day_month, people might well not use them, and would still be disappointed
that "month" wasn't what they expected.

The CF conformance document has a recommendation that "year" and "month" should
be used "with caution". I don't what the CF checker currently does with this.
We could change it to a recommendation that they should *not* be used, in which
case the checker would give a warning if they were.

Best wishes

Jonathan

----- Forwarded message from Bärring Lars  -

> Date: Thu, 18 Oct 2018 13:31:10 +
> From: Bärring Lars 
> To: Martin Juckes - UKRI STFC , David Blodgett
>, Ryan Abernathey 
> Cc: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] 'months since' and 'years since' time units
>
> Dear Martin, David, all,
>
> As Klaus points out, the aim of my suggestion is to make software using CF 
> aware of the fact that the unit "year" is different depending on which 
> calendar the model is implementing. To give an example:
> If I want to know when the global average temperature has increased by 1.5C, 
> or 4C, above pre-industrial time in the CMIP5 ensemble I will get  answers as 
> a timedelta in days. As this is not really helpful I might feel inclined to 
> convert this to years, but now UDUNITS definition of year is not helpful for 
> those models having a 360_day or 365_day calendar. However, with the 
> calendar-aware definition of year such a calculation would be supported 
> without having to deal with it manually.
>

Re: [CF-metadata] ice_sheet/land_ice confusion

[Martin Juckes - UKRI STFC]

e_on_land could be confused with land_ice. In addition, 
> ice_on_land could be confusing because snow *is* ice; there isn't a clear 
> distinction between snow and non-snow ice, and ice_and_snow_on_land could 
> mean the same as ice_on_land. Therefore I suggest that we made ice_on_land 
> into an alias of ice_and_snow_on_land.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Alison Pamment - UKRI STFC 
>  -
>
> > Date: Wed, 17 Oct 2018 15:05:06 +
> > From: Alison Pamment - UKRI STFC 
> > To: Karl Taylor , Martin Juckes - UKRI STFC
> >  , "CF-metadata (cf-metadata@cgd.ucar.edu)"
> >  
> > Subject: Re: [CF-metadata] ice_sheet/land_ice confusion
> >
> > Dear Karl et al.,
> >
> > Thank you all for the comments in this discussion, which I have been 
> > watching with interest.
> >
> > I think we can regard the three existing land ice area_types as nested:
> > ice_sheets= Grounded ice sheets + Floating ice shelves;
> > land_ice= ice_sheets + Glaciers + Ice caps;
> > ice_on_land = land_ice + River ice + Lake ice + Other ice on land, e.g 
> > frozen flood water.
> >
> > In addition we have:
> > ice_and_snow_on_land = snow overlying ice_on_land + snow overlying
> > bare ground or vegetation
> >
> > As Martin says, ice_on_land and ice_and_snow_on_land were designed to work 
> > with LS3MIP standard names. They include all frozen terrestrial water and 
> > are therefore wider than the other two categories. I can't comment on 
> > whether or not they are currently being used in the CMIP6 archive, but 
> > certainly that was the intention. The reason was to enable the use of the 
> > surface_albedo standard name along with specifying an area_type, instead of 
> > introducing lots of separate albedo standard names for different surface 
> > types. This approach received support in the mailing list discussions of 
> > LS3MIP names. We also introduced some standard names: 
> > change_over_time_in_amount_of_ice_and_snow_on_land and 
> > change_over_time_in_amount_of_ice_and_snow_on_land. The definition of 
> > "ice_and_snow_on_land" in these names follows that of the area_type.
> >
> > Martin has supported Karl's suggestion to modify the description of 
> > ice_sheet. In addition, Martin and Jonathan have suggested adding Greenland 
> > and Antarctica as examples rather than part of the basic definition so that 
> > the area_type can also be used for paleoclimate models. That seems like a 
> > good approach, hence I suggest:
> > 'An area type of "ice_sheet" indicates where  ice sheets are present, for 
> > example, in the present climate this would refer to the Greenland and 
> > Antarctic ice sheets.  It includes both the grounded portion of those ice 
> > sheets (i.e., the portion resting on bedrock either above or below sea 
> > level) and the portion that is floating as ice shelves.  It excludes all 
> > other ice on land (in contrast to land_ice, which includes, for example, 
> > small mountain glaciers and in contrast to ice_on_land, which is 
> > comprehensively inclusive of all types of ice on land).'
> >
> > Karl has asked whether ice_on_land includes snow. I think it doesn't, 
> > because as already mentioned we have ice_and_snow_on_land as a separate 
> > area_type. Therefore, I support Karl's suggestion to modify the description 
> > of ice_on_land to make that point clear:
> > 'The area type "ice_on_land" means ice in glaciers, ice caps, grounded ice 
> > sheets (grounded and floating shelves), river and lake ice, and any other 
> > ice on a land surface, such as frozen flood water (but excluding snow). 
> > This is distinct from the area type 'land ice' which has a narrower 
> > definition. The area_type ice_and_snow_on_land is defined similarly, but 
> > includes lying snow.'
> >
> > It would also make sense to add a corresponding cross-reference in the 
> > description of ice_and_snow_on_land:
> > 'The area type "ice_and_snow_on_land" means ice in glaciers, ice caps, ice 
> > sheets (grounded and floating shelves), river and lake ice, any other ice 
> > on a land surface, such as frozen flood water, and snow lying on such ice 
> > or on the land surface. The area_type ice_on_land is defined similarly, but 
> > excludes lying snow.'
> >
> > I am cautious about Jonathan's suggestion to remove ice_on_land - it was 
> > introduced specifically to cope with CMIP6, so might it not be needed in 
> > due course? Also, I don't know that the Conventions have anything to sa

Re: [CF-metadata] 'months since' and 'years since' time units

[Martin Juckes - UKRI STFC]

Hello Klaus, All,

thanks for the correction, I see the problem now.

I also agree with your analysis, there is a huge edifice built on the ability 
to convert from one unit to another in a transparent way and we are helping 
ourselves if we undermine that.

On the other hand, as you say, there is a strong user demand. We have a similar 
problem dealing with the requirements of users who want to report their results 
in units of "kg Carbon" (e.g. as a measure of the amount of carbon dioxide in 
the atmosphere). Our response is "no, Carbon is not a unit" and they come back 
with "it is used as a unit by the IPCC, in reports reviewed by thousands and 
signed off by 180 heads of state, isn't that enough?" There would be a great 
benefit if we could meet such requirements without breaking the Unidata 
convention.

Your suggestion would work, with a new standard name of "month_number" or 
"calendar_month". Alternatively, we could use a standard name of "date" and 
allow either "calendar_month" or "calendar_year" as values of a "user_units" 
attribute (users find the units attribute useful, but as we can't use that for 
the current purpose without breaking Unidata). This could be used either as an 
auxiliary coordinate or directly as a coordinate:


float co2(date,pres,lat,lon) ;

co2:long_name = "Carbon dioxide flux at surface as kg carbon per unit area 
per second" ;
co2:standard_name = 
"surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon";

co2:units = "kg m-2 s-1" ;
co2:user_units = "kg Carbon m-2 s-1";
int date(date);
date:standard_name = "date";
date:user_units = "calendar_month since 1980-01-01";

We could follow David's suggestion -- which would, I think, amount to saying 
that "time" was a special case exempt from the usual Udunits rules, but I would 
prefer to use a new variable such as "date" for this and keep the narrower 
definition of "time" which matches the Unidata usage.



Regards,

Martin



From: CF-metadata  on behalf of Klaus 
Zimmermann 
Sent: 18 October 2018 12:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] 'months since' and 'years since' time units

Hello All,

On 18/10/18 13:08, Martin Juckes - UKRI STFC wrote:
> Hello All,
>
>
> I think the UNIDATA pull request referenced Jeff 
> (https://github.com/Unidata/cftime/pull/69) is mis-quoting the CF Convention. 
> As far as I can see, Unidata says that a month is exactly one 12th of a year, 
> and CF inherits this -- with the statement "For similar reasons the unit 
> month, which is defined in 
> udunits.dat<http://www.unidata.ucar.edu/software/udunits/> to be exactly 
> year/12, should also be used with caution."
>
>
> I can't see the difference between Lars's suggestion and the status quo. In 
> UNIDATA a day is clearly defined as "period of time equal to 24 hours", which 
> gives 84600 seconds.

The difference is merely that 'year' is defined as an alias for
'tropical_year' and is always 365.24219878125 days, regardless of
calendar. Lars suggestion could be implemented by introducing new units
along the lines of 'julian_month', 'gregorian_month', 'sidereal_month', etc.

Indeed, for the 360 day calendar, this would lead exactly to Roy's
suggestion with '30_day_month' as a new unit allowing one to write
'30_day_month since ...'.

Also Ryan is correct that basically any human reading the month units
will understand them in the same way; I even think this holds generally
for all calendars. The problems will come from software where packages
will use the generic udunits api to convert these times to seconds or
hours, for example to determine frequencies, or simply to the same
calendar to homogenize data from different sources.

Hence, I don't think this approach is a good idea: The fact is, months
and years just don't fit very well in the whole units framework. They
are unique in that there is no simple relation given by scale factor and
offset with other time units. Just to stress this point: In all units
from albedo to yard you can perform the conversion to a different unit
for the same quantity independent from the value of the quantity. For
years and months it depends on intimate knowledge of the calendar and on
the date in question. Therefore, as the cf convention already states,
months and years really shouldn't be used as units for the time axis;
rather 'days since ...' together with a calendar in the attributes are
the best option at the moment. Together with a package like calcalcs[1],
this allows for relatively straightforward conversion to/from a (,
MM, dd) triple.

Of course, on the other hand as Jeff noted, months are exceedingly
popular as a unit and with good reason. But perhaps we could borr

Re: [CF-metadata] 'months since' and 'years since' time units

[Martin Juckes - UKRI STFC]

Hello All,


I think the UNIDATA pull request referenced Jeff 
(https://github.com/Unidata/cftime/pull/69) is mis-quoting the CF Convention. 
As far as I can see, Unidata says that a month is exactly one 12th of a year, 
and CF inherits this -- with the statement "For similar reasons the unit month, 
which is defined in udunits.dat 
to be exactly year/12, should also be used with caution."


I can't see the difference between Lars's suggestion and the status quo. In 
UNIDATA a day is clearly defined as "period of time equal to 24 hours", which 
gives 84600 seconds.

regards,
Martin




From: CF-metadata  on behalf of Bärring Lars 

Sent: 18 October 2018 09:29:50
To: Ryan Abernathey; whitaker.jeff...@gmail.com; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] 'months since' and 'years since' time units

Hi,

I have have come to think about this from a somewhat different perspective. For 
some analyses, as well as when calculating certain derived climatological 
statistics (aka climate indices), using datasets based on different calendars 
the problem becomes obvious.

In the model world of a 365-day GCM one year _is_ 365 days, and in a 360_day 
GCM a year _is_ 360 days. In the case of a gregorian/standard calendar GCM I am 
not sure whether it is 365.25 or 365.242198781 but this is in practice less of 
a problem.

For datasets based non-standard calendars imposing the current UDUNITS 
definition of a year leads to complications that require workarounds if one is 
interested in for example the time elapsed until something happens or the 
duration of some (long-lasting) events. One way to partly mitigate these issues 
would be to use the time unit of years_since_START or months_since_START, but 
this is warned against in the CF Conventions and may software tools do not 
support it .

The fundamental issue is the inconsistency between the GCM year and the UDUNITS 
year. So I would like to call on the wisdom of this list to see whether the CF 
Convention could include a modification to the definition of a year and month:

* standard calendar (no change)
1 day = 84600 seconds
1 year = 365.242198781 days
1 month = 365.242198781 / 12 days

* 365_day calendar
1 day = 84600 seconds
1 year = 365 days
1 month = 365 / 12 days

* 360_day calendar
1 day = 84600 seconds
1 year = 360 days
1 month = 360 / 12 days

That is, the seconds per day ratio is not changed thus maintaining the 
consistency to other SI units. And, for the 360_day calendar month follows the 
suggestion by Ryan and Jeffrey.


Kind regards,
Lars

--
Lars Bärring

FDr, Forskare
PhD, Research Scientist

SMHI  /  Swedish Meteorological and Hydrological Institute
Rossby Centre
SE - 601 76 NORRKÖPING
Tel / Phone: +46 (0)11 495 8604
Fax: +46 (0)11 495 8001
Besöksadress / Visiting address: Folkborgsvägen 17

Från: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] för Ryan Abernathey 
[ryan.abernat...@gmail.com]
Skickat: den 17 oktober 2018 21:22
Till: whitaker.jeff...@gmail.com
Kopia: cf-metadata@cgd.ucar.edu
Ämne: Re: [CF-metadata] 'months since' and 'years since' time units

Hi everyone,

I am that user, and I'm new to this mailing list. Thank you all for your work 
on CF conventions. It's such a valuable effort!

I want to note that this was inspired by the proliferation of datasets in the 
wild that use "month" as their units. For example, nearly all of the IRI Data 
Library does this, in conjunction with a 3"60_day" calendar (example: 
https://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCEP-NCAR/.CDAS-1/.MONTHLY/.Diagnostic/.surface/.temp/).

My impression from talking to data providers is that no one is using "360_day" 
calendar and "months" as units, and then expecting "months" to be interpreted 
as 365.242198781/12 days. They all expect it to be interpreted as 30 days. 
While there are various workarounds that can be used at different levels of the 
software stack, the best solution, IMHO, is to explicitly allow in CF 
conventions what Jeff proposed: "months and years be interpreted as calendar 
months and years for those calendars where they have a fixed length". I don't 
think this will break existing applications.

Thanks,
Ryan

On Wed, Oct 17, 2018 at 3:06 PM Jeffrey Whitaker 
mailto:whitaker.jeff...@gmail.com>> wrote:
Hi:  I'm a developer of the 'cftime' python package 
(https://github.com/Unidata/cftime).  A user submitted a pull request 
(https://github.com/Unidata/cftime/pull/69) that implements support for a 
30-day calendar month time unit for the '360_day' CF calendar.  Although using 
a 'month' time unit is a tricky proposition in general, for this calendar it 
seems straightforward since every month has the same length.  However, in the 
discussion of the pull request it was pointed out that CF expects  that "the 
value of the units attribute is a string that can be recognized by UNIDATA’s 
Udunits package", and that UDUNITS defines a 

Re: [CF-metadata] ice_sheet/land_ice confusion

[Martin Juckes - UKRI STFC]

Hello All,


I agree with Karl's suggestion that it is useful to mention Greenland and 
Antarctica to clarify the intended meaning of "ice_sheet", and also with with 
Jonathan point that there needs to be a caveat (perhaps "present era", rather 
than "modern world" -- the latter is often used to describe a much shorter 
timescale than we want here).


The CMIP approach to dividing the world is a little different from the approach 
Evan : the term "land_ice" has been introduced long ago and includes floating 
ice shelves. This could be described as a process driven approach: "land_ice" 
includes ice formed on land which has moved out to sea and has very different 
characteristics to "sea_ice", which is ice that has formed at sea.


In CMIP6 "land" is interpreted as including floating ice shelves when it refers 
to the surface. In CMIP5 the models did not include a physical representation 
of floating ice shelves, so areas such as the Ross Sea would generally be 
represented as grounded ice sheets, I believe. For CMIP6, we did discuss 
restricting "land" to exclude floating ice shelves and introducing a new area 
type for the broader meaning, but in the end opted for continuity with CMIP5.  
"land" is also taken to include lakes -- the fact that we have a small number 
of lakes and inland seas resolved in CMIP models is not yet reflected in the 
area types.


Consequently, Evan's requirements will need some new area types which will need 
to be named carefully to avoid confusion with existing ones.

"ice_on_land" appears to have been introduced following a discussion of LS3MIP 
variables, one of which was originally an albedo of ice and snow on land but 
later got changed to an albedo of snow on land, hence this area type is not 
used.

regards,
Martin

From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 17 October 2018 05:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] ice_sheet/land_ice confusion

Hi all,

In CMIP5  only one of the three terms under discussion here was used:
"land_ice" (in the standard_name "land_ice_area_fraction"), which was
described as "fraction of grid cell occupied by "permanent" ice (i.e.,
glaciers)."  This was a "fixed" (time-independent) field.

As far as I can tell, "ice_on_land" isn't needed by CMIP6 (and it wasn't
needed or used in CMIP5).  I don't know (or have forgotten) what led it
to be introduced as a valid surface type.

best regards,
Karl

On 10/14/18 7:30 AM, Jonathan Gregory wrote:
> Reposting this, which  didn't get to the list.
>
> Dear Karl, Sophie, Alison
>
> If we define ice_sheet to mean those of Greenland and Antarctica, it won't be
> applicable for palaeoclimate, so I think it's too restrictive. Although it's
> a continuum, there is a distinction between "ice sheet" and "glacier"
> that refers to size, with "ice-cap" being in the middle (and not used in IPCC
> to make things simpler). Ice sheets are big enough to bury the bedrock
> topography, so that the surface shape is determined by mass balance and
> dynamics. Glaciers are smaller, and confined within bedrock topography,
> which strongly influences their shape.
>
> If we want to mention Greenland and Antarctica explicitly, it would be a
> good idea to say "for example, in the modern world".
>
> No doubt it was discussed and I have forgotten, but being confronted with it
> now, I feel rather uncomfortable about there being distinct area_types of
> land_ice and ice_on_land. These types are not self-describing, in that the
> difference in wording does not convey anything about the difference in 
> meaning.
>
> When and why was ice_on_land introduced?
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Karl Taylor  -
>
>> Date: Tue, 9 Oct 2018 11:44:53 -0700
>> From: Karl Taylor 
>> To: "Nowicki, Sophie (GSFC-6150)" ,
>>   "cf-metadata@cgd.ucar.edu" 
>> CC: Jonathan Gregory 
>> Subject: Re: ice_sheet/land_ice confusion
>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
>>   Gecko/20100101 Thunderbird/52.9.1
>>
>> Thanks, Sophie, for your quick response.  Given your clarification,
>> perhaps we might replace the description of ice_sheet, which
>> currently reads:
>>
>>  > ice_sheet: An area type of "ice sheet" indicates where ice sheets are
>>  > present. It includes both grounded ice sheets resting over bedrock and
>>  > ice shelves flowing over the ocean, but excludes ice-caps and glaciers
>>  > (in contrast to land_ice, which includes all components).
>>
>> with this description:
>>
>> ice_sheet: An area type of "ice_sheet" indicates where the Greenland
>> and Antarctic ice sheets are present.  It includes both the grounded
>> portion of those ice sheets (i.e., the portion resting on bedrock
>> either above or below sea level) and the portion that is floating as
>> ice shelves.  It excludes all other ice on land (in contrast to
>> land_ice, which includes, for example, small mountain glaciers and
>> in 

[CF-metadata] Ocean content tendencies due to sedimentation -- sign ambiguity in CMIP usage

[Martin Juckes - UKRI STFC]

Hello All,


there is a problem with the way 4 CMIP6 variables use standard names defined 
for tendencies due to sedimentation. Sedimentation in CF means sedimentation in 
water, so sedimentation of a substance always leads to a negative tendency of 
the amount of that substance suspended in the ocean. In CMIP6, following CMIP5 
usage, standard names for tendencies of amounts of substances in the ocean have 
been used for variables with long names which imply that they are negative 
tendencies, i.e. loss rates. E.g.

- frfe "Iron Loss to Sediments"  
tendency_of_ocean_mole_content_of_iron_due_to_sedimentation.


We recently dealt with a similar issue for atmospheric deposition rates: 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020204.html and the 
solution (http://cfeditor.ceda.ac.uk/proposal/3225 ) was to introduce new 
standard names of the form "minus_tendency_...".


For the four ocean variables (frfe, frn, fric, froc) I propose 4 new standard 
names:

 minus_tendency_of_ocean_mole_content_of_inorganic_carbon_due_to_sedimentation
 minus_tendency_of_ocean_mole_content_of_organic_carbon_due_to_sedimentation
minus_tendency_of_ocean_mole_content_of_iron_due_to_sedimentation (as in CMIP5)
minus_tendency_of_ocean_mole_content_of_elemental_nitrogen_due_to_denitrification_and_sedimentation


These all correspond to minus one times the quantity defined by existing 
standard names.


More details about the 4 CMIP variables are given on the Data Request github 
site: 
https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/344


regards,

Martin


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CMIP6: just one name remaining!

[Martin Juckes - UKRI STFC]

Dear Didier, Jean-Yves,


we need to clear up one remaining ambiguity in the definition of the variable 
sw2H, which is related to deuterium in sea water.


In the table that Jean-Yves posted on github 
(https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/316) 
it is described with a long name "1H2HO in sea water" and description "Ratio of 
2H in sea water".


Is the quantity you want the ratio of 1H.2H.O the number of molecules to the 
total 1H2.O molecules?


For the sw18O and sw17O variables we used standard names which refer to the 
ration of 18O atoms to 16O atoms (e.g. 
isotope_ratio_of_18O_to_16O_in_sea_water_excluding_solutes_and_solids  -- the 
last part is needed because "sea_water" in standard names is interpreted as 
including not only the H2O but also the solutes and suspended solids that go 
with it). That approach won't work here if we are dealing with only the 
deuterium in water molecules which contain a single deuterium atom.


The term "isotope" is usually, as far as I can tell, interpreted as referring 
to atoms, but can be used to refer to molecules. I suggest we mention the fact 
that we are referring to a ratio of molecular isotopes in the standard name (if 
my interpretation above is correct). We have some agreed terms such as 
precipitation_flux_containing_single_2H (for pr2H) which are related to 1H.2H.O 
molecules. We decided not to try to use a name for the molecule, as different 
people have different names for these isotopes, and instead we have tried to 
spell out the detail in the standard name.


Following that approach here, we might use:

water_molecule_isotope_ratio_of_single_2H_to_double_1H_in_sea_water_excluding_solutes_and_solids


Does that make sense? I'm I correct in thinking that you want the ration of 
2H.1H.O to 1H2.O for this variable?


regards,

Martin



From: Pamment, Alison (STFC,RAL,RALSP)
Sent: 04 July 2018 16:19
To: CF-metadata (cf-metadata@cgd.ucar.edu); Juckes, Martin (STFC,RAL,RALSP)
Subject: CMIP6: just one name remaining!


Dear Martin,



After all the progress in recent weeks we have now reached the position where 
there is just one CMIP6 name remaining to be agreed.



It is the PMIP name:

isotope_ratio_of_2H_to_1H_in_sea_water_excluding_solutes_and_solids (1)

‘The phrase "ratio_of_X_to_Y" means X/Y. The phrase "isotope_ratio" is used in 
the construction isotope_ratio_of_A_to_B where A and B are both named isotopes. 
It means the ratio of the number of atoms of A to the number of atoms of B 
present within a medium. "H" means the element "hydrogen" and "2H" is the 
stable isotope "hydrogen-2", usually called "deuterium". "1H" is the stable 
isotope "hydrogen-1". The phrase "in_sea_water_excluding_solutes_and_solids" 
means that the standard name refers to the composition of the sea water medium 
itself and does not include material that may be dissolved or suspended in the 
medium.’



The question that we need to resolve is whether '2H' includes water composed of 
both HDO and D2O. The name as it stands could be understood to mean the ratio 
of all 2H to 1H in sea water, regardless of whether the 2H occurs in heavy or 
semiheavy water, but this may not be the intention.



To publish the last few CMIP names I am planning a ‘mini update’ to the 
standard name table next week. It would be great if we could sort out this 
remaining one in time to include it!



Best wishes,

Alison



--

Alison Pamment Tel: +44 1235 778065

NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk

STFC Rutherford Appleton Laboratory

R25, 2.22

Harwell Oxford, Didcot, OX11 0QX, U.K.


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CMIP6: just one name remaining!

[Martin Juckes - UKRI STFC]

Dear Alison,


excellent, that is great news.


I'll send a query to the PMIP isotope experts later this morning.


Martin



From: Pamment, Alison (STFC,RAL,RALSP)
Sent: 04 July 2018 16:19
To: CF-metadata (cf-metadata@cgd.ucar.edu); Juckes, Martin (STFC,RAL,RALSP)
Subject: CMIP6: just one name remaining!


Dear Martin,



After all the progress in recent weeks we have now reached the position where 
there is just one CMIP6 name remaining to be agreed.



It is the PMIP name:

isotope_ratio_of_2H_to_1H_in_sea_water_excluding_solutes_and_solids (1)

‘The phrase "ratio_of_X_to_Y" means X/Y. The phrase "isotope_ratio" is used in 
the construction isotope_ratio_of_A_to_B where A and B are both named isotopes. 
It means the ratio of the number of atoms of A to the number of atoms of B 
present within a medium. "H" means the element "hydrogen" and "2H" is the 
stable isotope "hydrogen-2", usually called "deuterium". "1H" is the stable 
isotope "hydrogen-1". The phrase "in_sea_water_excluding_solutes_and_solids" 
means that the standard name refers to the composition of the sea water medium 
itself and does not include material that may be dissolved or suspended in the 
medium.’



The question that we need to resolve is whether '2H' includes water composed of 
both HDO and D2O. The name as it stands could be understood to mean the ratio 
of all 2H to 1H in sea water, regardless of whether the 2H occurs in heavy or 
semiheavy water, but this may not be the intention.



To publish the last few CMIP names I am planning a ‘mini update’ to the 
standard name table next week. It would be great if we could sort out this 
remaining one in time to include it!



Best wishes,

Alison



--

Alison Pamment Tel: +44 1235 778065

NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk

STFC Rutherford Appleton Laboratory

R25, 2.22

Harwell Oxford, Didcot, OX11 0QX, U.K.


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Standard name table updated

[Martin Juckes - UKRI STFC]

Dear Alison,


I agree with these suggestions.


I think we could consider a the statement of an alias (as in X is an alias of 
Y, where Y is a valid current term) to be equivalent to a definition of X. As 
corrections to definitions are allowed, it would make sense to allow 
corrections to the alias statements (though not to the alias terms themselves),


regards,

Martin



From: Pamment, Alison (STFC,RAL,RALSP)
Sent: 04 July 2018 11:44
To: Juckes, Martin (STFC,RAL,RALSP); CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: Standard name table updated

Dear Martin,

I think you are right about these names. The aliases were created in Version 55 
so they have only existed for three weeks. Instead of describing them as 
tendencies in snow and ice amount, we could make them tendencies of atmospheric 
water vapor:
surface_snow_and_ice_sublimation_flux -> 
tendency_of_atmosphere_mass_content_of_water_vapor_due_to_sublimation_of_surface_snow_and_ice
surface_snow_sublimation_amount -> 
tendency_of_atmosphere_mass_content_of_water_vapor_due_to_sublimation_of_surface_snow


These would have the correct sign, i.e., positive when sublimation occurs, and 
the correct units (kg m-2 s-1). Would that be acceptable?

The name tendency_of_surface_ice_amount_due_to_sublimation has also been in the 
table for three weeks. If we follow the above scheme it should be 
tendency_of_atmosphere_mass_content_of_water_vapor_due_to_sublimation_of_surface_ice.

In view of the short time the aliases and the new name have existed, and since 
they were added to write new data for CMIP6, I am going to suggest that we 
simply change them. This is an unusual step and if the terms had existed for 
longer we wouldn't be able to do this, but given the circumstances, I think it 
is the cleanest way of solving the problem. I think it is the most sensible 
option for correcting aliases that are actually erroneous. It will also help to 
avoid repeating the same mistake in the future.

Do you agree with this approach?

Best wishes,
Alison


From: Juckes, Martin (STFC,RAL,RALSP)
Sent: 03 July 2018 13:00:51
To: Pamment, Alison (STFC,RAL,RALSP); CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: Standard name table updated

Dear Alison,

I'm sorry, I think we overlooked a sign inconsistency in the discussion of 
sublimation fluxes from snow. Aliases were introduced:
surface_snow_and_ice_sublimation_flux -> 
tendency_of_surface_snow_and_ice_amount_due_to_sublimation
surface_snow_sublimation_amount -> 
tendency_of_surface_snow_amount_due_to_sublimation

Sublimation fluxes are generally interpreted as being positive when the solid 
phase converts to vapor, and hence a sublimation flux should correspond to 
minus the tendency of the amount of the solid phase.

Can we un-alias these terms, or introduce "minus_tendency_" terms and adjust 
the aliases?

We would also need a "minus_tendency_of_surface_ice_amount_due_to_sublimation" 
term. In this case "tendency_of_surface_ice_amount_due_to_sublimation" was a 
new term introduced in response to a requirement for a sublimation flux term 
... but it expresses minus the required flux.

regards,
Martin

From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 12 June 2018 13:40:23
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Standard name table updated

Dear All,

The standard name table has been updated. The current version is now Version 
55, dated 12 June 2018. The changes have also been published on the NERC 
Vocabulary Server. All changes are listed at the end of this message.

The next update of the standard name table is planned for 2 July 2018. There 
are now approximately 50 names that remain to be agreed for CMIP6, plus a small 
number of new area types. As soon as these are resolved I will begin to address 
the list of non-CMIP related names that are currently waiting for attention.

Best wishes,
Alison

1. New names

a. Names proposed by Martin Juckes for CMIP6 PMIP

minus_tendency_of_atmosphere_mass_content_of_dust_dry_aerosol_particles_due_to_deposition
 (Canonical units: kg m-2 s-1)
minus_tendency_of_atmosphere_mass_content_of_insoluble_dust_dry_aerosol_particles_due_to_deposition
 (Canonical units: kg m-2 s-1)
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect
 (Canonical units: W m-2)
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky
 (Canonical units: W m-2)
surface_net_downward_shortwave_dust_ambient_aerosol_particles_direct_radiative_effect
 (Canonical units: W m-2)
surface_net_downward_shortwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky
 (Canonical units: W m-2)
tendency_of_atmosphere_mass_content_of_dust_dry_aerosol_particles_due_to_deposition
 (Canonical units: kg m-2 s-1)

Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into snowpack

[Martin Juckes - UKRI STFC]

For the river water names we have one vote for
> inward_water_volume_transport_along_river_channel
> outward_water_volume_transport_along_river_channel
and one for
> incoming_water_volume_transport_along_river_channel
> outgoing_water_volume_transport_along_river_channel.


I will vote for incoming/outgoing. The qualifiers upward/downward are used to 
express a sign convention, so that upward_flux_of_X is minus the downward flux, 
and we use upwelling/downwelling to express fluxes associated with photons 
moving in different directions. By association, I think it will be clearer if 
we avoid the "inward" and "outward" here,


regards,

Martin




From: Pamment, Alison (STFC,RAL,RALSP)
Sent: 04 July 2018 11:48:39
To: Juckes, Martin (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu; 
j.m.greg...@reading.ac.uk
Subject: Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into 
snowpack

Dear Martin and Jonathan,

Thank you both for the very useful discussion of these names. I agree with 
Martin that the existing sensible_heat_flux names probably should become 
turbulent_heat_flux names. There are only four of them, but I will address 
those in a separate thread.

For the LS3MIP heat flux name we now have:
tendency_of_thermal_energy_content_of_surface_snow_due_to_rainfall_temperature_excess_above_freezing
'The phrase "tendency_of_X" means derivative of X with respect to time. 
"Content" indicates a quantity per unit area.Thermal energy is the total 
vibrational energy, kinetic and potential, of all the molecules and atoms in a 
substance. The phrase "surface_snow" means snow lying on the surface. The 
quantity with standard name 
tendency_of_thermal_energy_content_of_surface_snow_due_to_rainfall_temperature_excess_above_freezing
 is the heat energy carried by rainfall reaching the surface. It is calculated 
relative to the heat that would be carried by rainfall reaching the surface at 
zero degrees Celsius. It is calculated as the product QrainCpTrain, where Qrain 
is the mass flux of rainfall reaching the surface (kg m-2 s-1), Cp is the 
specific heat capacity of water and Train is the temperature in degrees Celsius 
of the rain water reaching the surface. The specification of a physical process 
by the phrase due_to_process means that the quantity named is a single term in 
a sum of terms which 
 together compose the general quantity named by omitting the phrase.'

This name is accepted for publication in the standard name table and will be 
added in the next update.

For the river water names we have one vote for
> inward_water_volume_transport_along_river_channel
> outward_water_volume_transport_along_river_channel
and one for
> incoming_water_volume_transport_along_river_channel
> outgoing_water_volume_transport_along_river_channel.

Martin, it looks as though you will have the casting vote! Which do you prefer?

Best wishes,
Alison

________
From: CF-metadata  on behalf of Martin Juckes 
- UKRI STFC 
Sent: 03 July 2018 12:02
To: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk
Subject: Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into 
snowpack


Dear Alison, Jonathan,


Thanks for these final suggestions. I agree with these proposals. I have a 
reservation about the interpretation of "sensible heat flux" which was 
mentioned in the discussion, but that does not need to delay approval of these 
proposed terms which neatly avoid the problem.


The usage of "sensible heat flux" outside the standard name list consistently 
refer to it as a thermodynamic property, not something which is specific to a 
particular medium. In the existing standard names which include the phrase 
"sensible_heat_flux" the descriptive text suggests that it applies to heat flux 
through air alone, implicitly excluding any heat flux conveyed by 
precipitation. It looks to me as though the wording is a reflection of the 
state of models at the time the standard names were defined, when it may have 
been reasonable to omit mention of transport of heat by precipitation and 
equate sensible heat flux at the surface to turbulent heat flux at the surface. 
As models can now, apparently, resolve the sensible heat flux associated with 
falling rain, I can't see any reason for maintaining an interpretation of 
"sensible_heat_flux" in standard names which conflicts with the normal usage.


regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 01 July 2018 18:27
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into snowpack

Dear Alison and Martin

> tendency_of_thermal_energy_content_of_surface_snow_due_to_rainfall_temperature_excess_above_freezing

I think this  suggestion of Alison's is very good, to describe 

Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 feature depth

[Martin Juckes - UKRI STFC]

n_thermal_energy_content_of_ice_and_snow_on_land (J m-2)
'The phrase "change_over_time_in_X" means change in a quantity X over a 
time-interval, which should be defined by the bounds of the time coordinate. 
The surface called "surface" means the lower boundary of the atmosphere. 
"Content" indicates a quantity per unit area. Thermal energy is the total 
vibrational energy, kinetic and potential, of all the molecules and atoms in a 
substance. The phrase "ice_and_snow_on_land" means ice in glaciers, ice caps, 
ice sheets & shelves, river and lake ice, any other ice on a land surface, such 
as frozen flood water, and snow lying on such ice or on the land surface.'

This name is accepted for inclusion in the standard name table and will be 
added in the next update.

I have added change_over_time_in_groundwater_amount and 
change_over_time_in_river_water_amount in this week's update, as there were no 
remaining questions about their definitions.

> 2.1 CMIP6 short name dmlt. Depth to soil thaw (CliC) Depth from surface to 
> the zero degree isotherm. Above this isotherm T > 0o, and below this line T < 
> 0o.

I think we are now agreed on
depth_at_shallowest_isotherm_defined_by_soil_temperature (m)
'Depth is the vertical distance below the surface. A soil temperature profile 
may go through one or more local minima or maxima. The "depth at shallowest 
isotherm" is the depth of the occurrence closest to the soil surface of an 
isotherm of the temperature specified by a coordinate variable or scalar 
coordinate variable with standard name soil_temperature.'

We have also agreed the creation of a new area type, unfrozen_ground.

I have added unfrozen_ground to the area type table in this week's update. The 
standard name is now accepted and will be included in the next update.

If we can clarify the point about grounded ice sheets in the definition of 
land_water_amount I think all the names in this thread will be finalised.

Best wishes,
Alison


From: CF-metadata  on behalf of Martin Juckes 
- UKRI STFC 
Sent: 03 July 2018 11:13
To: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk
Subject: Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 
feature depth

Dear Alison


For 1.6 (change in surface water amount, CMIP6 variable dsw) the term should 
reflect the choice for surface water amount (CMIP6 variable sw), and I've tried 
to summarise the latest comments here:

http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020327.html


<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020327.html>This would 
make it change_over_time_in_land_surface_liquid_water_amount ... but  that name 
is still under discussion. This surface liquid water amount is distinct from 
the water storage term represented by the land_water_amount which has already 
been agreed. The confusion between the two may have originated from my earlier 
posts to this list.


For 1.5 and 1.8, Hyungjun's comments refer to the terrestrial water storage 
term which is a rather specialist term excluding both floating ice and grounded 
ice which is displacing sea water. The majority of snow and ice terms deal with 
the broader definition of land surface to include floating land ice. The study 
of the finer details of what is happening around the grounding line which 
separates ice shelves and sheets is happening in ISMIP6, and they are not 
interested in the LS3MIP variables which will use terms defined in 1.5 and 1.8. 
Taking these things into account, I believe that we should define terms 1.5 and 
1.8  to include ice shelves and sheets.


I agree with the other suggestion,

regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 01 July 2018 18:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 
feature depth

Dear Alison

These all look fine to me. Thanks very much

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Fri, 29 Jun 2018 09:16:51 +
> From: Alison Pamment - UKRI STFC 
> To: "cf-metadata@cgd.ucar.edu" 
> Cc: Hyungjun Kim 
> Subject: Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1
>feature depth
>
> Dear Martin and Jonathan,
>
> Just picking up on this thread again - this is the 3rd (and final) group of 
> LS3MIP names remaining to be resolved.
>
> We have now received clarification of how various parts of the land liquid 
> water and ice budget are calculated, which I copy below so that we have a 
> record in this public discussion:
> > 1) If we preferentially focus on mass balance, it would be straightforward 
> > to have:
> >  + soil moisture : total water in soil column
> > + water table depth : depth of saturation
> > + groundwater re

Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 feature depth

[Martin Juckes - UKRI STFC]

 a 
substance. The phrase "ice_and_snow_on_land" means ice in glaciers, ice caps, 
ice sheets & shelves, river and lake ice, any other ice on a land surface, such 
as frozen flood water, and snow lying on such ice or on the land surface.'

This name is accepted for inclusion in the standard name table and will be 
added in the next update.

I have added change_over_time_in_groundwater_amount and 
change_over_time_in_river_water_amount in this week's update, as there were no 
remaining questions about their definitions.

> 2.1 CMIP6 short name dmlt. Depth to soil thaw (CliC) Depth from surface to 
> the zero degree isotherm. Above this isotherm T > 0o, and below this line T < 
> 0o.

I think we are now agreed on
depth_at_shallowest_isotherm_defined_by_soil_temperature (m)
'Depth is the vertical distance below the surface. A soil temperature profile 
may go through one or more local minima or maxima. The "depth at shallowest 
isotherm" is the depth of the occurrence closest to the soil surface of an 
isotherm of the temperature specified by a coordinate variable or scalar 
coordinate variable with standard name soil_temperature.'

We have also agreed the creation of a new area type, unfrozen_ground.

I have added unfrozen_ground to the area type table in this week's update. The 
standard name is now accepted and will be included in the next update.

If we can clarify the point about grounded ice sheets in the definition of 
land_water_amount I think all the names in this thread will be finalised.

Best wishes,
Alison


From: CF-metadata  on behalf of Martin Juckes 
- UKRI STFC 
Sent: 03 July 2018 11:13
To: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk
Subject: Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 
feature depth

Dear Alison


For 1.6 (change in surface water amount, CMIP6 variable dsw) the term should 
reflect the choice for surface water amount (CMIP6 variable sw), and I've tried 
to summarise the latest comments here:

http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020327.html


<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020327.html>This would 
make it change_over_time_in_land_surface_liquid_water_amount ... but  that name 
is still under discussion. This surface liquid water amount is distinct from 
the water storage term represented by the land_water_amount which has already 
been agreed. The confusion between the two may have originated from my earlier 
posts to this list.


For 1.5 and 1.8, Hyungjun's comments refer to the terrestrial water storage 
term which is a rather specialist term excluding both floating ice and grounded 
ice which is displacing sea water. The majority of snow and ice terms deal with 
the broader definition of land surface to include floating land ice. The study 
of the finer details of what is happening around the grounding line which 
separates ice shelves and sheets is happening in ISMIP6, and they are not 
interested in the LS3MIP variables which will use terms defined in 1.5 and 1.8. 
Taking these things into account, I believe that we should define terms 1.5 and 
1.8  to include ice shelves and sheets.


I agree with the other suggestion,

regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 01 July 2018 18:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 
feature depth

Dear Alison

These all look fine to me. Thanks very much

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Fri, 29 Jun 2018 09:16:51 +
> From: Alison Pamment - UKRI STFC 
> To: "cf-metadata@cgd.ucar.edu" 
> Cc: Hyungjun Kim 
> Subject: Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1
>feature depth
>
> Dear Martin and Jonathan,
>
> Just picking up on this thread again - this is the 3rd (and final) group of 
> LS3MIP names remaining to be resolved.
>
> We have now received clarification of how various parts of the land liquid 
> water and ice budget are calculated, which I copy below so that we have a 
> record in this public discussion:
> > 1) If we preferentially focus on mass balance, it would be straightforward 
> > to have:
> >  + soil moisture : total water in soil column
> > + water table depth : depth of saturation
> > + groundwater recharge : water flux at water table (which should be 
> > base flow if water table depth is lower than model soil depth)
> >
> > 2) In terrestrial hydrology, cold processes and associated storage are 
> > treated with liquid phase processes in general.
> > Therefore, it would be more useful to have them in separated variables.
> >
> > 3) I mostly agree with you suggestion, but because of reason 2), it would 
> &g

Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6

[Martin Juckes - UKRI STFC]

Dear Dirk,


a fair comment ... I withdraw my suggested re-ordering,


regards,

Martin



From: CF-metadata  on behalf of Dirk Notz 

Sent: 03 July 2018 14:34
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6

Dear Alison, Jonathan, Martin,

I like the names that Jonathan suggested. With Martin's definition, I
find it more difficult to figure out how to read the various parts of
the name, i.e. people could wonder about a "sea-ice maximum" etc.

Best,

 Dirk




Dr. Dirk Notz
http://www.mpimet.mpg.de/~notz.dirk

Am 03.07.2018 um 13:26 schrieb Martin Juckes - UKRI STFC:
> Dear Alison, Jonathan,
>
>
> I can see some benefit in the re-ordering the parts of the name, but we 
> generally start names with something more specific to the parameter (e.g. 
> sea_surface_wave_maximum_period).
>
>
> How about:
>
> sea_ice_maximum_over_coordinate_rotation_of_horizontal_shear_strain_rate 
> (s-1) and
>
> sea_ice_maximum_over_coordinate_rotation_of_horizontal_shear_stress (N m-1)?
>
>
> regards,
>
> Martin
>
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 28 June 2018 14:49
> To: Pamment, Alison (STFC,RAL,RALSP)
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6
>
> Dear Alison
>
> Yes, that's what I meant. Thanks for considering it.
>
> Best wishes
>
> Jonathan
>
> On Thu, Jun 28, 2018 at 01:41:23PM +, Alison Pamment - UKRI STFC wrote:
>> Date: Thu, 28 Jun 2018 13:41:23 +
>> From: Alison Pamment - UKRI STFC 
>> To: "'j.m.greg...@reading.ac.uk'" ,
>>  "cf-metadata@cgd.ucar.edu" 
>> Subject: RE: [CF-metadata] SIMIP: 5 standard names and one area type for
>>  CMIP6
>>
>> Dear Jonathan,
>>
>> Thank you for commenting on these names. If I understand you correctly, then 
>> the two 'maximum' names and definitions would be rearranged as follows.
>>
>> maximum_over_coordinate_rotation_of_sea_ice_horizontal_shear_strain_rate 
>> (s-1)
>> '"Sea ice" means all ice floating in the sea which has formed from freezing 
>> sea water, rather than by other processes such as calving of land ice to 
>> form icebergs. Axial strain is the symmetric component of the tensor 
>> representing the gradient of internal forces (e.g. in ice). Strain rate 
>> refers to off-diagonal element(s) of the strain tensor (a single element for 
>> horizontal shear strain). "Horizontal" refers to the local horizontal in the 
>> location of the sea ice, i.e., perpendicular to the local gravity vector. 
>> Each of the strain components is defined with respect to a frame of 
>> reference. "Coordinate rotation" refers to the range of all possible 
>> orientations of the frame of reference. The shear strain has a maximum value 
>> relative to one of these orientations. The second invariant of strain rate, 
>> often referred to as the maximum shear strain [rate], is the maximum over 
>> coordinate rotations of the shear strain rate.'
>>
>> maximum_over_coordinate_rotation_of_sea_ice_horizontal_shear_stress (N m-1)
>> ' "Sea ice" means all ice floating in the sea which has formed from freezing 
>> sea water, rather than by other processes such as calving of land ice to 
>> form icebergs. Axial stress is the symmetric component of the tensor 
>> representing the gradient of internal forces (e.g. in ice). Shear stress 
>> refers to off-diagonal element(s) of the stress tensor (a single element for 
>> horizontal shear stress). "Horizontal" refers to the local horizontal in the 
>> location of the sea ice, i.e., perpendicular to the local gravity vector. 
>> Each of the stress components is defined with respect to a frame of 
>> reference. "Coordinate rotation" refers to the range of all possible 
>> orientations of the frame of reference. The shear stress has a maximum value 
>> relative to one of these orientations. The second invariant of stress, often 
>> referred to as the maximum shear stress, is the maximum over coordinate 
>> rotations of the shear stress.'
>>
>> I tend to agree that these are a little easier to understand at first sight. 
>> I'm happy to write the names and definitions this way, if Dirk and Bruno 
>> have no objections.
>>
>> N.B. I have added 'Axial' to the start of the second sentence of the 
>> definitions and replaced 'stress' with 'strain' for the first definition, as 
>> requested by Dirk.
>>
>> Best wishes,
>> Aliso

Re: [CF-metadata] Standard name table updated

[Martin Juckes - UKRI STFC]

Dear Alison,


I'm sorry, I think we overlooked a sign inconsistency in the discussion of 
sublimation fluxes from snow. Aliases were introduced:

surface_snow_and_ice_sublimation_flux -> 
tendency_of_surface_snow_and_ice_amount_due_to_sublimation
surface_snow_sublimation_amount -> 
tendency_of_surface_snow_amount_due_to_sublimation


Sublimation fluxes are generally interpreted as being positive when the solid 
phase converts to vapor, and hence a sublimation flux should correspond to 
minus the tendency of the amount of the solid phase.


Can we un-alias these terms, or introduce "minus_tendency_" terms and adjust 
the aliases?


We would also need a "minus_tendency_of_surface_ice_amount_due_to_sublimation" 
term. In this case "tendency_of_surface_ice_amount_due_to_sublimation" was a 
new term introduced in response to a requirement for a sublimation flux term 
... but it expresses minus the required flux.


regards,

Martin


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 12 June 2018 13:40:23
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Standard name table updated

Dear All,

The standard name table has been updated. The current version is now Version 
55, dated 12 June 2018. The changes have also been published on the NERC 
Vocabulary Server. All changes are listed at the end of this message.

The next update of the standard name table is planned for 2 July 2018. There 
are now approximately 50 names that remain to be agreed for CMIP6, plus a small 
number of new area types. As soon as these are resolved I will begin to address 
the list of non-CMIP related names that are currently waiting for attention.

Best wishes,
Alison

1. New names

a. Names proposed by Martin Juckes for CMIP6 PMIP

minus_tendency_of_atmosphere_mass_content_of_dust_dry_aerosol_particles_due_to_deposition
 (Canonical units: kg m-2 s-1)
minus_tendency_of_atmosphere_mass_content_of_insoluble_dust_dry_aerosol_particles_due_to_deposition
 (Canonical units: kg m-2 s-1)
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect
 (Canonical units: W m-2)
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky
 (Canonical units: W m-2)
surface_net_downward_shortwave_dust_ambient_aerosol_particles_direct_radiative_effect
 (Canonical units: W m-2)
surface_net_downward_shortwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky
 (Canonical units: W m-2)
tendency_of_atmosphere_mass_content_of_dust_dry_aerosol_particles_due_to_deposition
 (Canonical units: kg m-2 s-1)
toa_longwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky
 (Canonical units: W m-2)

b. Names proposed by Martin Juckes for CMIP6 LS3MIP

canopy_snow_amount (Canonical units: kg m-2)
liquid_water_mass_flux_into_soil_due_to_surface_snow_melt (Canonical units: kg 
m-2 s-1)
mass_content_of_water_in_soil_layer_defined_by_root_depth (Canonical units: kg 
m-2)
nudging_increment_in_mass_content_of_water_in_soil (Canonical units: kg m-2)
nudging_increment_in_snow_and_ice_amount_on_land (Canonical units: kg m-2)
river_water_volume_transport_into_cell (Canonical units: m3 s-1)
river_water_volume_transport_out_of_cell (Canonical units: m3 s-1)
surface_upward_latent_heat_flux_due_to_sublimation (Canonical units: W m-2)
tendency_of_surface_ice_amount_due_to_sublimation (Canonical units: kg m-2 s-1)

c. Names proposed by Alison Pamment for CMIP6 DAMIP

mole_fraction_of_ox_in_air (Canonical units: 1)
photolysis_rate_of_molecular_oxygen (Canonical units: s-1)
photolysis_rate_of_ozone (Canonical units: s-1)
tendency_of_mole_concentration_of_ox_in_air_due_to_chemical_and_photolytic_production
 (Canonical units: mol m-3 s-1)
tendency_of_mole_concentration_of_ox_in_air_due_to_chemical_destruction 
(Canonical units: mol m-3 s-1)

2. New aliases

Two aliases were added in this update to make existing sublimation names 
consistent with new names agreed for LS3MIP and with other existing names.
surface_snow_and_ice_sublimation_flux -> 
tendency_of_surface_snow_and_ice_amount_due_to_sublimation
surface_snow_sublimation_amount -> 
tendency_of_surface_snow_amount_due_to_sublimation

3. Modifications to definitions of existing names

a. A definition of 'boundary layer mixing' was agreed during the discussion of 
names recently added for CMIP6 DynvarMIP: ' "Boundary layer mixing" means 
turbulent motions that transport heat, water, momentum and chemical 
constituents within the atmospheric boundary layer and affect exchanges between 
the surface and the atmosphere. The atmospheric boundary layer is typically 
characterised by a well-mixed sub-cloud layer of order 500 metres, and by a 
more extended conditionally unstable layer with boundary-layer clouds up to 2 
km. (Reference: IPCC Third Assessment Report, Working Group 1: The Scientific 
Basis, 7.2.2.3, https://www.ipcc.ch/ipccreports/tar/wg1/273.htm).' 

Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6

[Martin Juckes - UKRI STFC]

Dear Alison, Jonathan,


I can see some benefit in the re-ordering the parts of the name, but we 
generally start names with something more specific to the parameter (e.g. 
sea_surface_wave_maximum_period).


How about:

sea_ice_maximum_over_coordinate_rotation_of_horizontal_shear_strain_rate (s-1) 
and

sea_ice_maximum_over_coordinate_rotation_of_horizontal_shear_stress (N m-1)?


regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 28 June 2018 14:49
To: Pamment, Alison (STFC,RAL,RALSP)
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6

Dear Alison

Yes, that's what I meant. Thanks for considering it.

Best wishes

Jonathan

On Thu, Jun 28, 2018 at 01:41:23PM +, Alison Pamment - UKRI STFC wrote:
> Date: Thu, 28 Jun 2018 13:41:23 +
> From: Alison Pamment - UKRI STFC 
> To: "'j.m.greg...@reading.ac.uk'" ,
>  "cf-metadata@cgd.ucar.edu" 
> Subject: RE: [CF-metadata] SIMIP: 5 standard names and one area type for
>  CMIP6
>
> Dear Jonathan,
>
> Thank you for commenting on these names. If I understand you correctly, then 
> the two 'maximum' names and definitions would be rearranged as follows.
>
> maximum_over_coordinate_rotation_of_sea_ice_horizontal_shear_strain_rate (s-1)
> '"Sea ice" means all ice floating in the sea which has formed from freezing 
> sea water, rather than by other processes such as calving of land ice to form 
> icebergs. Axial strain is the symmetric component of the tensor representing 
> the gradient of internal forces (e.g. in ice). Strain rate refers to 
> off-diagonal element(s) of the strain tensor (a single element for horizontal 
> shear strain). "Horizontal" refers to the local horizontal in the location of 
> the sea ice, i.e., perpendicular to the local gravity vector. Each of the 
> strain components is defined with respect to a frame of reference. 
> "Coordinate rotation" refers to the range of all possible orientations of the 
> frame of reference. The shear strain has a maximum value relative to one of 
> these orientations. The second invariant of strain rate, often referred to as 
> the maximum shear strain [rate], is the maximum over coordinate rotations of 
> the shear strain rate.'
>
> maximum_over_coordinate_rotation_of_sea_ice_horizontal_shear_stress (N m-1)
> ' "Sea ice" means all ice floating in the sea which has formed from freezing 
> sea water, rather than by other processes such as calving of land ice to form 
> icebergs. Axial stress is the symmetric component of the tensor representing 
> the gradient of internal forces (e.g. in ice). Shear stress refers to 
> off-diagonal element(s) of the stress tensor (a single element for horizontal 
> shear stress). "Horizontal" refers to the local horizontal in the location of 
> the sea ice, i.e., perpendicular to the local gravity vector. Each of the 
> stress components is defined with respect to a frame of reference. 
> "Coordinate rotation" refers to the range of all possible orientations of the 
> frame of reference. The shear stress has a maximum value relative to one of 
> these orientations. The second invariant of stress, often referred to as the 
> maximum shear stress, is the maximum over coordinate rotations of the shear 
> stress.'
>
> I tend to agree that these are a little easier to understand at first sight. 
> I'm happy to write the names and definitions this way, if Dirk and Bruno have 
> no objections.
>
> N.B. I have added 'Axial' to the start of the second sentence of the 
> definitions and replaced 'stress' with 'strain' for the first definition, as 
> requested by Dirk.
>
> Best wishes,
> Alison
>
> --
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
> -Original Message-
> From: CF-metadata  On Behalf Of Jonathan 
> Gregory
> Sent: 25 June 2018 14:23
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6
>
> Dear Alison and Dirk
>
> > It has taken me a little while to understand this name, but I am beginning 
> > to grasp it!
> > sea_ice_horizontal_shear_strain_rate_maximum_over_coordinate_rotation
> > (s-1)
>
> I think the concept and definition are fine, but the name could maybe be made 
> a bit clearer. The last sentence of the definition seems clearer in turning it
> round: could you likewise make the name
>   maximum_over_coordinate_rotation_of_sea_ice_horizontal_shear_strain_rate
>
> ?
>
> Cheers
>
> Jonathan
> ___
> 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

Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into snowpack

[Martin Juckes - UKRI STFC]

Dear Alison, Jonathan,


Thanks for these final suggestions. I agree with these proposals. I have a 
reservation about the interpretation of "sensible heat flux" which was 
mentioned in the discussion, but that does not need to delay approval of these 
proposed terms which neatly avoid the problem.


The usage of "sensible heat flux" outside the standard name list consistently 
refer to it as a thermodynamic property, not something which is specific to a 
particular medium. In the existing standard names which include the phrase 
"sensible_heat_flux" the descriptive text suggests that it applies to heat flux 
through air alone, implicitly excluding any heat flux conveyed by 
precipitation. It looks to me as though the wording is a reflection of the 
state of models at the time the standard names were defined, when it may have 
been reasonable to omit mention of transport of heat by precipitation and 
equate sensible heat flux at the surface to turbulent heat flux at the surface. 
As models can now, apparently, resolve the sensible heat flux associated with 
falling rain, I can't see any reason for maintaining an interpretation of 
"sensible_heat_flux" in standard names which conflicts with the normal usage.


regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 01 July 2018 18:27
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into snowpack

Dear Alison and Martin

> tendency_of_thermal_energy_content_of_surface_snow_due_to_rainfall_temperature_excess_above_freezing

I think this  suggestion of Alison's is very good, to describe the rainfall
temperature flux as a change in heat content due to X rather than as the
problematic X heat flux. Thanks.

> inward_water_volume_transport_along_river_channel
> outward_water_volume_transport_along_river_channel
> OR
> incoming_water_volume_transport_along_river_channel
> outgoing_water_volume_transport_along_river_channel.

I prefer the latter pair still, but I don't mind.

Best wishes

Jonathan
___
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

Re: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 feature depth

[Martin Juckes - UKRI STFC]

frozen flood water, snow lying on the surface and 
> intercepted by the canopy) and subsurface water (liquid and frozen soil 
> water, groundwater).'
>
> Okay?
>
> > 1.8 CMIP6 short name dtesn. Change in snow/ice cold content (CliC)
> > "thermal_energy_content_of_surface_snow" exists, we can extend with 
> > "_and_ice".
> >
> > The ice includes all the ice above ground, including glaciers, ice sheets 
> > and floating ice shelves.
> >
> > + Propose:
> > + change_over_time_in_thermal_energy_content_of_surface_snow_and_ice
> > + (J m-2)
>
> As for proposal 1.5 I am changing my suggestion to use the newly defined 
> 'ice_and_snow_on_land':
> change_over_time_in_thermal_energy_content_of_ice_and_snow_on_land (J m-2).
> 'The phrase "change_over_time_in_X" means change in a quantity X over a 
> time-interval, which should be defined by the bounds of the time coordinate. 
> The surface called "surface" means the lower boundary of the atmosphere. 
> "Content" indicates a quantity per unit area. Thermal energy is the total 
> vibrational energy, kinetic and potential, of all the molecules and atoms in 
> a substance. The phrase "ice_and_snow_on_land" means ice in glaciers, ice 
> caps, ice sheets & shelves, river and lake ice, any other ice on a land 
> surface, such as frozen flood water,  and snow lying on such ice or on the 
> land surface.
>
> Okay? As with 1.5, I'd like to double check that we should include floating 
> ice shelves, because this seems to differ from Hyungjun's description.
>
> > 2. Feature depths
> >
> > 2.1 CMIP6 short name dmlt. Depth to soil thaw (CliC) Depth from
> > surface to the zero degree isotherm. Above this isotherm T > 0o, and below 
> > this line T < 0o.
> >
> > When the surface temperature is above 0K and there is frozen soil at
> > some point beneath the surface, thawed_soil_depth is the distance from the 
> > surface to the first 0K isotherm. When there is no thawed soil layer, the 
> > parameter should be reported as missing.
> >
> > + Proposed: thawed_soil_depth
>
> For this one I previously suggested:
> depth_at_shallowest_isotherm_defined_by_soil_temperature (m)
> 'Depth is the vertical distance below the surface. A soil temperature profile 
> may go through one or more local minima or maxima. The "depth at shallowest 
> isotherm" is the depth of the occurrence closest to the soil surface of an 
> isotherm of the temperature specified by a coordinate variable or scalar 
> coordinate variable with standard name soil_temperature.'
>
> We already have soil_temperature as a standard name. Following discussion 
> (off list) with Martin, I think we also need to add a new area type of 
> 'unfrozen_soil' because this quantity should only be reported where the soil 
> at the surface is thawed.
>
> Okay?
>
> Best wishes,
> Alison
>
> --
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
> -Original Message-
> From: CF-metadata  On Behalf Of Martin 
> Juckes - UKRI STFC
> Sent: 17 May 2018 16:50
> To: cf-metadata@cgd.ucar.edu
> Cc: Hyungjun Kim 
> Subject: [CF-metadata] Standard names for LS3MIP: 8 temporal changes + 1 
> feature depth
>
> Dear All,
>
> Following some discussion with Hyungjun, I'd like to propose the following 
> new standard names to support the LS3MIP CMIP6 data request.
>
> 1.Changes over time
>
> 1.1 dcwChange in Interception Storage  [kg m-2]
> The standard name "canopy_water_amount" exists.
> + Propose: change_over_time_in_canopy_water_amount
>
> 1.2 dgwChange in Groundwater  [kg m-2]
> We do not currently have any terms specifically for groundwater, so this 
> concept needs to be defined: the following is proposed: "Groundwater is the 
> subsurface water in the saturated zone."
> + propose: change_over_time_in_groundwater_amount
>
> 1.3 drivwChange in River Storage  [kg m-2]
> There is no existing term for the amount of water in rivers, though there are 
> several for the rate of flow.  Such terms as exist make no explicit reference 
> to the definition of the what is meant by river water, so a clarification 
> note is proposed.
>
> + Propose: change_over_time_in_river_water_amount
> + "River water amount refers to the water in the fluvial system (stream and 
> floodplain)".
>
> 1.4 dslwChange in soil moisture  [kg m-2]
> Relates to changes in quanti

Re: [CF-metadata] Precipitation fractions for LS3MIP

[Martin Juckes - UKRI STFC]

Dear Alison,


thanks, those names look good.


I see a slight ambiguity in the description where it refers to "the horizontal 
domain" being defined by a coordinate variable: there are two horizontal 
domains here, the snow covered area for the numerator and a reference area for 
the denominator of the fraction. The denominator could be, for example, 
rainfall onto  land or onto the total grid area. What is the "domain" that is 
intended to be represented by the coordinate variable?


regards,

Martin




From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 28 June 2018 16:50
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Precipitation fractions for LS3MIP

Dear Karl, Jonathan and Martin,

I think we are edging toward agreement on these names. Karl and Jonathan have 
agreed that these could be mass_fraction_of_X_falling_onto_surface_snow, where 
X is rainfall or solid_precipitation, and I am also okay with this solution. 
Martin, if you are happy with the names as written below then I think these two 
can be accepted.

mass_fraction_of_rainfall_falling_onto_surface_snow (1)
'The quantity with standard name 
mass_fraction_of_rainfall_falling_onto_surface_snow is the mass of rainfall 
falling onto snow as a fraction of the mass of rainfall falling within the area 
of interest. The horizontal domain over which the quantity is calculated is 
described by the associated coordinate variables and coordinate bounds or by a 
coordinate variable or scalar coordinate variable with the standard name of 
"region" supplied according to section 6.1.1 of the CF conventions. The phrase 
"surface_snow" means snow lying on the surface.'

mass_fraction_of_solid_precipitation_falling_onto_surface_snow (1)
'Solid precipitation refers to the precipitation of water in the solid phase. 
Water in the atmosphere exists in one of three phases: solid, liquid or vapor. 
The solid phase can exist as snow, hail, graupel, cloud ice, or as a component 
of aerosol. The quantity with standard name 
mass_fraction_of_solid_precipitation_falling_onto_surface_snow is the mass of 
solid precipitation falling onto snow as a fraction of the mass of solid 
precipitation falling within the area of interest. The horizontal domain over 
which the quantity is calculated is described by the associated coordinate 
variables and coordinate bounds or by a coordinate variable or scalar 
coordinate variable with the standard name of "region" supplied according to 
section 6.1.1 of the CF conventions. The phrase "surface_snow" means snow lying 
on the surface.'

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Karl Taylor
Sent: 25 June 2018 18:06
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Precipitation fractions for LS3MIP

Hi Jonathan,

I had objected to mass_fraction earlier, but if it is immediately followed, for 
example, by "of_rainfall" it won't get confused with the mass_fraction used to 
describe a single species in a mixture.

I don't like "amount" because although it is a ratio, I think it normally 
describes an extensive quantity, and the fractions we want to report could be 
instantaneous.  I suppose rainfall_flux or rainfall_rate would also be o.k.

Your suggestion to start with, for example, "mass_fraction_of_rainfall ..." 
would also be o.k. with me.

best regards,
Karl

On 6/25/18 6:38 AM, Jonathan Gregory wrote:
> Dear Alison et al.
>
> I still find myself tripping over rainfall_mass. Why not
> rainfall_amount, rainfall_flux or rainfall_rate? They would all be the
> same number, since it's a *fraction*. Another possibility would be a 
> reordering to
>mass_fraction_of_rainfall_falling_onto_surface_snow (1)
>mass_fraction_of_solid_precipitation_falling_onto_surface_snow (1)
> We have many mass_fraction names, and consistency could be good.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Alison Pamment - UKRI STFC
>  -
>
>> Date: Thu, 21 Jun 2018 11:34:45 +
>> From: Alison Pamment - UKRI STFC 
>> To: 'Karl Taylor' , Martin Juckes - UKRI STFC
>> , "CF-metadata (cf-metadata@cgd.ucar.edu)"
>> 
>> Subject: Re: [CF-metadata] Precipitation fractions for LS3MIP
>>
>> Dear Martin, Jonathan, Karl,
>>
>> I have had another look at these two names and amended the definitions in 
>> the light of the discussion.
>>
>> fraction_of_rainfall_mass_falling_onto_surface_snow (1) 'The quantity
>> with standard name fraction_of_rainfall_mass_falling_onto_surface_

Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP.

[Martin Juckes - UKRI STFC]

Dear Jonathan,


I'd like to pick up on a comment which you made in the thread about ocean terms 
"expressed_as_heat_content" 
(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020364.html). You refer 
to the fact that "thermal energy" is sometimes used in the standard names. I've 
looked into this to try to understand different usages both within the standard 
name list and elsewhere.

We have two names referring to thermal energy (always as thermal energy 
content):

  *   
change_over_time_in_thermal_energy_content_of_vegetation_and_litter_and_soil
  *   thermal_energy_content_of_surface_snow

and 4 referring to sensible heat (always as sensible heat flux):

  *   integral_wrt_time_of_surface_downward_sensible_heat_flux
  *   surface_downward_sensible_heat_flux
  *   surface_upward_sensible_heat_flux
  *   upward_sensible_heat_flux_in_air

Usage of "sensible heat" vs. "thermal energy" outside the CF standard names is 
variable, but there appears to be a consensus that "sensible heat" is not 
really a measure of the energy but a measure of the energy released or absorbed 
as a result of temperature changes. This is consistent with the terms we have. 
Energy fluxes at the surface are partitioned into radiative, latent and 
sensible heat fluxes.

"thermal_energy_content" appears to be equivalent to "heat_content", which is 
used in 16 oceanographic terms and is part of the discussion on the thread I've 
linked to above, except that "heat_content" is only used in the construct 
"X_expressed_as_heat_content". This makes sense, as "heat_content" is a rather 
ambiguous concept, and it is the specification of "X" which makes the 
oceanographic terms precise.

"thermal energy" is related to "internal energy", but, as far as I can make 
out, "internal energy" is a thermodynamic state function which is well defined, 
while "thermal energy" is sometimes taken as a measure of heat needed to reach 
the current state which depends on the thermodynamic pathway take, and 
sometimes defined in terms of the kinetic and potential energy of molecules. 
The two thermal energy content terms in the CF standard names are less 
precisely defined than the oceanographic heat content terms, but I think this 
reflects the state of the art in the different domains, with heat content being 
a more central concern in oceanography.

After reading this, I can see that sensible heat fluxes are, in some sense, 
intrinsically related to a temperature anomalies, so there is no need to put 
"anomaly" explicitly in the name, so I would be happy to go with 
surface_downward_sensible_heat_flux_due_to_rainfall_temperature. As I 
understand it, we are looking at terms in a heat budget, where the heat is 
measured relative to a reference state at zero Centigrade, so that adding rain 
water at zero Centigrade leaves the heat content unchanged. If we were looking 
at the full thermodynamic energy, then there is of course a certain amount of 
energy in water at zero Centigrade, so this concept of a reference state is 
important in all these sensible heat flux and heat content terms.

regards,
Martin




From: CF-metadata  on behalf of Martin Juckes 
- UKRI STFC 
Sent: 12 June 2018 16:01
To: Jonathan Gregory; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP.

Dear Jonathan,


(1) downward flux of heat in rainfall


OK, I can see the problem. surface_downward_sensible_heat_flux is currently 
defined to be the downward flux of sensible heat associated with air motions. 
That doesn't look right to me. Rain clearly has sensible heat and clearly 
carries it downwards. "Sensible heat" is widely used synonym for thermal 
energy, so I don't think we can justify restricting it to apply only to the 
thermal energy of air.


I still think it is better to use "anomaly" ... it would not break anything and 
would make the term clearer.


(2) I can see your point about a lake. I was thinking of rivers, and at any 
point on the river the water is flowing from upstream to downstream of that 
point. A lake is a special case in that it is a flat area, so it is normal to 
speak of upstream and downstream areas relative to the lake. For a grid cell 
with complex sub-grid topography, I think it is more natural to talk about 
inward and outward flow.


regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 12 June 2018 14:50
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP.

Dear Martin and Alison

> surface_downward_sensible_heat_flux_due_to_rainfall_temperature_anomaly
>
> The rainfall temperature anomaly is the temperature of the snow relative to 
> the zero Celsius. The sensible heat flux due the rain

Re: [CF-metadata] tendency_of_sea_water_conservative_temperature_expressed_as_heat_content units

[Martin Juckes - UKRI STFC]

Hello Jonathan,


I agree that the "integral_wrt_depth_" is a little surprising here, but I think 
it is better than saying temperature when we mean "temperature times thickness".


In any case, we have a term:

tendency_of_sea_water_potential_temperature_expressed_as_heat_content

which is intended to be the tendency of 
integral_wrt_depth_of_sea_water_potential_temperature_expressed_as_heat_content,
 which doesn't look right. There should be consistency here -- either include 
"integral_wrt_depth_" in both cases, or exclude it in both cases.


When dealing with mass, the use of "content" in a standard name automatically 
implies a vertical integral, so we might get away without stating it explicitly 
here, but it is a slightly different usage. The current help text includes the 
remark that '"Content" indicates a quantity per unit area.', which I find a 
little cryptic: perhaps it could be expanded to : '"Content" indicates a 
quantity per unit area, integrated over height or depth.'


The text explaining "expressed_as_heat_content" could also be adjusted 
(currently: 'The phrase "expressed_as_heat_content" means that this quantity is 
calculated as the specific heat capacity times density of sea water multiplied 
by the conservative temperature of the sea water in the grid cell') to refer to 
the multiplication by thickness. "expressed_as_heat_content" is only used with 
sea water potential temperature and conservative temperature.  E.g.

'The phrase "expressed_as_heat_content" means that this quantity is calculated 
as the specific heat capacity times density of sea water multiplied by the 
conservative temperature of the sea water in the grid cell and integrated over 
depth. If used for a layer heat content, coordinate bounds should be used to 
define the extent of the layers'.

With these modifications, I think we could justify staying with

tendency_of_sea_water_potential/conservative_temperature_expressed_as_heat_content
 and dropping the  "integral _wrt_depth_" from

integral_wrt_depth_of_sea_water_potential_temperature_expressed_as_heat_content 
and integral_wrt_depth_of_sea_ice_temperature_expressed_as_heat_content (these 
are the only two terms which combine integral_wrt_depth and 
expressed_as_heat_content).

regards,
Martin






From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 25 June 2018 10:57
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] 
tendency_of_sea_water_conservative_temperature_expressed_as_heat_content units

Dear Alison and Steve

I suggest that we can be more relaxed about units for X_expressed_as_Y, so that
X and Y don't have to be dimensionally equivalent. We can express the change in
temperature of an ocean layer as a change in heat content by using the heat
capacity - that's the idea of these names, and similarly for the names with
tendency_of_sea_water_salinity_expressed_as_salt_content, which have the units
(kg m-2 s-1) expected for a tendency in salt content, not a tendency in
salinity (which would be s-1). It's useful to mention temperature (rather than
heat content) because it allows us to specify whether we mean potential or
conservative temperature.

I agree that we could insert integral_wrt_depth_of, for both set of names.
However this seems a bit surprising since the names are generally for 3D
quantities. Each cell applies to one ocean layer. The "integral" is just the
cell value multiplied by the cell thickness.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Mon, 25 Jun 2018 09:28:28 +
> From: Alison Pamment - UKRI STFC 
> To: Stephen Griffies - NOAA Federal 
> CC: Martin Juckes - UKRI STFC ,
>"cf-metadata@cgd.ucar.edu" , Jonathan
>Gregory , Karl Taylor ,
>"Durack, Paul J." 
> Subject: Re:
>
> tendency_of_sea_water_conservative_temperature_expressed_as_heat_content
>units
>
> Dear Stephen,
>
> Thank you for getting back to me.
>
> A CF standard name for integral_wrt_depth need not necessarily be interpreted 
> as a full ocean depth quantity. The limits of the integral are specified by 
> placing bounds on the vertical coordinate variablle that is attached to the 
> data variable. The bounds can be used to indicate that an integral has been 
> calculated over a single model layer, for example. We recently discussed on 
> the mailing list how to specify the limits if the integral is calculated over 
> the whole ocean depth and it was agreed that if no limits (i.e. bounds) are 
> specified then the integral is assumed to be full depth. This clarification 
> has now been added to the definitions of all the integral_ wrt_depth standard 
> names.
>
> I think Martin's question regarding the units is

Re: [CF-metadata] Standard names for RFMIP and GeoMIP

[Martin Juckes - UKRI STFC]

ure".

Thank you for clarifying the definition of this quantity. I think we should say 
in the name what the asymmetry factor refers to - it could be describing the 
shape of the particle, for example, but here we are talking about radiative 
properties. Would radiative_asymmetry_factor_of_ambient_aerosol_particles
be acceptable?

This name is still under discussion.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


From: Robert Pincus <mailto:robert.pin...@colorado.edu>
Sent: 14 June 2018 07:33
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: Pamment, Alison (STFC,RAL,RALSP)
Subject: Re: [CF-metadata] Standard names for RFMIP and GeoMIP

Martin -

We do want the asymmetry parameter using the cosine-weighted integral; I'm 
sorry if we have implied differently. The standard name 
asymmetry_factor_of_ambient_aerosol_particles would be perfect.What we want is 
results only for ambient aerosol.

To inform future requests, yes, it would be sensible to ask for combinations 
such as e.g. asymmetry_factor_of_ambient_aerosol_particles_and_clouds . 
Combining asymmetry factors is unambiguous if one also knows the optical depth 
and single-scattering albedo of each component.

- Robert


> On Jun 13, 2018, at 1:22 PM, Martin Juckes - UKRI STFC 
> <mailto:martin.juc...@stfc.ac.uk> wrote:
>
> Dear Robert,
>
>
> we have a question about the RFMIP variable "aerasymbnd" for which you
> requested the standard name
>
> volume_spectral_asymmetry_factor_in_air_due_to_ambient_aerosol_particles.
>
> Markus Fiebig commented that the definition you gave, which refers to
> the ratio of backscattered to forward scattered radiation, usually
> goes under the name "backscatter fraction", rather than asymmetry
> factor, which is a cosine weighted integral (see
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2015/058422.html). ttp://mailman.cgd.ucar.edu/pipermail/cf-metadata/2015/058422.html)>
>
> Which do you want, asymmetry factor or backscatter fraction?
>
> The phrase "X_due_to_Y" in a standard name implies that there is a quantity 
> "X" which can be written as a sum of terms due to "Y" and other processes. 
> Here, it looks to me as though we are looking at a property of the aerosol 
> particles, so asymmetry_factor_of_ambient_aerosol_particles may be more 
> appropriate. For the quantity which you want here, does it make sense to add 
> contributions from different sources, e.g. asymmetry factor due to aerosol + 
> asymmetry factor due to cloud ice?
>
> regards,
> Martin
>
>
> 
> From: Juckes, Martin (STFC,RAL,RALSP)
> Sent: 13 June 2018 13:09
> To: Pamment, Alison (STFC,RAL,RALSP); CF-metadata
> (mailto:cf-metadata@cgd.ucar.edu)
> Subject: Re: [CF-metadata] Standard names for RFMIP and GeoMIP
>
>
> Dear Alison,
>
>
> Thank you for reviewing all these. The "_clear_sky_and_no_aerosol" names look 
> good.
>
>
> 6. & 7.
>
> For the albedo terms: You are right about "spectral": this was included 
> because the CMIP6 variables which need this standard name are requested in 
> spectral frequency bands, but the term requested is an albedo, not an albedo 
> per unit wave-number.
>
>
> I believe that "spherical" and "hemispherical" have distinct meanings when 
> applied to radiation terms. From ISO 9288-1996 ["Thermal insulation - Heat 
> transfer by radiation .."]: "hemispherical" is used for quantities which "are 
> related to all directions along which a surface element can emit or receive 
> radiation", which I think applies here. Spherical irradiance refers to the 
> total irradiance incident on a point from all angles. Hence, I think we 
> should stay with hemispherical reflectance. On the other hand, "surface 
> hemispherical reflectance" and "surface albedo" appear to mean the same 
> thing, and we already have "surface_albedo", so it may be better to use that 
> phrase here. I had not looked into this enough before, so thank you for 
> querying the original suggestion.
>
>
> The surface_albedo term makes no reference to the wavelength at which it 
> should be calculated, but I believe that it is generally considered to be a 
> quantity associated with shortwave radiation. Hence, I suggest we can drop 
> this qualifier -- but only if everyone agrees that surface_albedo should, at 
> least by default, apply to solar radiation.
>
>
> Finally, "downwelling" is 

Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6

[Martin Juckes - UKRI STFC]

e specification of a physical process by the phrase "due_to_" process means 
that the quantity named is a single term in a sum of terms which together 
compose the general quantity named by omitting the phrase. Melt ponds occur on 
top of the existing sea ice.'

We already use the term "melt pond" in area types, I think we could also use it 
in standard names. What do you think?

> (2) snmassacrosslineSnow mass flux through straits  (kg s-1)
>
> For sea ice we have sea_ice_transport_across_line. We might try 
> snow_transport_across_line, but that would probably be interpreted as 
> including transport of snow in the atmosphere, hence:
> snow_transport_across_line_due_to_sea_ice_dynamics
>

For Dirk's proposal 1.12 we have agreed to use 
tendency_of_surface_snow_amount_due_to_sea_ice_dynamics, so I think your 
suggestion fits very well with this and existing names. The definition would be 
based on agreed and existing names as follows:
'Transport "across_line" means that which crosses a particular line on the 
Earth's surface; formally this means the integral along the line of the normal 
component of the transport. The specification of a physical process by the 
phrase "due_to_" process means that the quantity named is a single term in a 
sum of terms which together compose the general quantity named by omitting the 
phrase. "Sea ice dynamics" refers to advection of sea ice. "Sea_ice" means all 
ice floating on the sea with the exception of floating ice shelves, which are 
regarded as land ice in models.'

This name is accepted for publication in the standard name table and will be 
added in the 2nd July update.

> (3a) sishevelMaximum shear strain rate of sea-ice velocity field  (s-1)
>
> Maximum shear strain rate of sea-ice velocity field (second shear strain 
> invariant: maximum is taken over coordinate rotations)
>
> sea_ice_horizontal_shear_strain_rate_maximum_over_coordinate_rotation
> Help text: "Stress is the symmetric component of the tensor representing the 
> gradient of internal forces (e.g. in ice). Shear stress refers to 
> off-diagonal element(s) of the stress tensor (a single element for horizontal 
> shear stress). The
> maximum over coordinate rotations of the shear strain rate, often referred to 
> as the maximum shear strain [rate], represents the second invariant of strain 
> rate."

I'm afraid I'm not expert enough to comment very usefully on these quantities. 
I note that the names sea_ice_x_internal_stress and sea_ice_y_internal_stress 
were agreed for Dirk's proposals 1.26 and 1.27. Would it be correct to describe 
the horizontal shear strain as also being 'internal'? If so, perhaps we should 
add it to the name.  I'm not sure what 'horizontal' means here - is it parallel 
to the sea-surface or some other surface such as the sea ice base perhaps? Or 
does it mean it's in the same plane as the x and y coordinates in Dirk's names? 
I note that the definition of 3c says 'Horizontal stress refers to the stress 
in the horizontal plane' but that still doesn't really explain what is 
considered to be horizontal in this context. If you are including 'maximum' in 
the name, does that mean it's an intrinsic part of how the variable is 
calculated by the model, rather than a statistic representative of an area of 
sea ice?  I'd welcome comments from anyone more knowledgeable than me about 
these quantities!

This name is still under discussion.

> (3b) sistremaxMaximum shear stress in sea ice  (N m-1)
> Maximum shear stress in sea ice (second stress invariant)
>
> sea_ice_horizontal_shear_stress_maximum_over_coordinate_rotation
>
> Help text: "Stress is the symmetric component of the tensor representing the 
> gradient of internal forces (e.g. in ice). Shear stress refers to 
> off-diagonal element(s) of the stress tensor (a single element for horizontal 
> shear stress). The
> maximum over coordinate rotations of the shear stress, often referred to as 
> the maximum shear stress, represents the second invariant of stress."

This name appears to be consistent with 3a and my comments and questions would 
be the same for this one.

This name is still under discussion.

> (3c) sistresaveAverage normal stress in sea ice  (N m-1)
> Average normal stress in sea ice (first stress invariant: average of diagonal 
> elements of the stress tensor)
>
> sea_ice_average_normal_horizontal_stress
> Help text: "Stress is the symmetric component of the tensor representing the 
> gradient of internal forces (e.g. in ice). Horizontal stress refers to the 
> stress in the horizontal plane. Average normal stress refers to the average 
> of the
> diagonal elements of the stress tensor and represents the first invariant of 
> stress."

Again I'd ask similar questions to those for 3a and 3b. By 'a

Re: [CF-metadata] Land and terrestrial water amounts in the CMIP6 data request

[Martin Juckes - UKRI STFC]

 Kim 
Sent: 14 June 2018 09:26
To: Juckes, Martin (STFC,RAL,RALSP); Chris Jones; Jean-Yves Peterschmitt; Karl 
Taylor; Pamment, Alison (STFC,RAL,RALSP)
Subject: Re: Land and terrestrial water amounts in the CMIP6 data request

Dear Martin and all,

I am sorry about my delayed response.
Please find my opinion below.

1) This ambiguity might come from diverse model representation of land
water continuum.
If we preferentially focus on mass balance, it would be straightforward
to have:
 + soil moisture : total water in soil column
 + water table depth : depth of saturation
 + groundwater recharge : water flux at water table (which should be
base flow if water table depth is lower than model soil depth)

2) In terrestrial hydrology, cold processes and associated storage are
treated with liquid phase processes in general.
Therefore, it would be more useful to have them in separated variables.

3) I mostly agree with you suggestion, but because of reason 2), it
would be better to be defined as (although it is same to yours
physically) summation of:
 + liquid phase surface water (water in rivers, wetlands, lakes,
vegetation, reservoirs, canopy interception)
 + snow ( interception), and ice, including grounded ice
sheets and ice on lakes etc, but excluding ice shelves floating in sea water
 + liquid subsurface water
 + solid subsurface water

Best regards,
Hyungjun


On 6/6/2018 12:17 AM, Martin Juckes - UKRI STFC wrote:
> Hello All,
>
>
> We have a few variables for water amounts, with some open questions. We 
> really need to resolve these questions this week, as many modelling groups 
> contributing to CMIP6 will not be able to deal with changes after that. Most 
> of the questions are about LS3MIP, but some relate to PMIP and C4MIP requests 
> as well, so please take a look and comment wherever you can.
>
>
> The main variables that these questions relate to are:
>
>
> mrtws [kg m-2], Terrestrial Water Storage, requested by LS3MIP, C4MIP and 
> PMIP;
>
>
> sw [kg m-2], Surface Water Storage (excluding snow and ice), requested by 
> LS3MIP;
>
>
> dgw [kg m-2], Change in Groundwater, requested by LS3MIP;
>
>
> mrso [kg m-2], Total Soil Moisture Content (CMIP5 variable, reused in CMIP6);
>
>
> qgwr [kg m-2 s-1], Groundwater recharge from soil layer (requested by LS3MIP);
>
>
> 1) We have opted for the following definition of groundwater: "Groundwater is 
> subsurface water below the depth of the water table, including soil moisture 
> and underground aquifers." It appears to be common usage to include soil 
> moisture as part of groundwater, but, if that is the case, what is meant by 
> the parameter qgwr, "Groundwater recharge from soil layer"? On the other 
> hand, our proposed definition for Terrestrial Water Storage, " It 
> includes surface water (water in rivers, wetlands, lakes, snow[, and ice], 
> vegetation and reservoirs) and subsurface water (soil moisture, 
> groundwater)", could be read as implying that soil moisture and groundwater 
> are separate. Would it make sense to consider "surface water", "soil 
> moisture" and "groundwater" as three independent water masses which combine 
> to give terrestrial water storage? Or, when we talk of "groundwater" in CMIP 
> models, do we mean the saturated portion of the soil moisture (i.e. there are 
> no rock aquifers)?
>
>
> 2) The terrestrial water storage definition implies that "surface water" is 
> "water in rivers, wetlands, lakes, snow, vegetation and reservoirs": does 
> this definition make sense for the LS3MIP variable "sw"? (allowing for the 
> fact that "sw" has the additional restriction that it only applies to liquid 
> water and so would exclude snow  and ice -- but the question is whether "sw" 
> should include liquid water in all the other categories);
>
>
> 3) The majority of our land surface variables are defined over land including 
> ice sheets and floating ice shelves. It appears that the parameter 
> "Terrestrial Water Storage" (TWS) is most widely used for analysis of sea 
> level rise, in which case it would make sense to exclude the floating ice 
> shelves. It appears that many existing studies of TWS exclude Greenland and 
> Antarctica, perhaps because analysis of the water budget in these regions is 
> a different science. However, with the (possible) advent of global climate 
> models that can represent the water budget consistently in these regions, we 
> should try to define variables in such a way that they can be used globally. 
> Hence, I propose clarifying the TWS definition to " It includes surface 
> water (water in rivers, wetlands, lakes, vegetation, reservoirs, 

Re: [CF-metadata] Standard names for RFMIP and GeoMIP

[Martin Juckes - UKRI STFC]

Dear Alison,


Thank you for reviewing all these. The "_clear_sky_and_no_aerosol" names look 
good.


6. & 7.

For the albedo terms: You are right about "spectral": this was included because 
the CMIP6 variables which need this standard name are requested in spectral 
frequency bands, but the term requested is an albedo, not an albedo per unit 
wave-number.


I believe that "spherical" and "hemispherical" have distinct meanings when 
applied to radiation terms. From ISO 9288-1996 ["Thermal insulation — Heat 
transfer by radiation .."]: "hemispherical" is used for quantities which "are 
related to all directions along which a surface element can emit or receive 
radiation", which I think applies here. Spherical irradiance refers to the 
total irradiance incident on a point from all angles. Hence, I think we should 
stay with hemispherical reflectance. On the other hand, "surface hemispherical 
reflectance" and "surface albedo" appear to mean the same thing, and we already 
have "surface_albedo", so it may be better to use that phrase here. I had not 
looked into this enough before, so thank you for querying the original 
suggestion.


The surface_albedo term makes no reference to the wavelength at which it should 
be calculated, but I believe that it is generally considered to be a quantity 
associated with shortwave radiation. Hence, I suggest we can drop this 
qualifier -- but only if everyone agrees that surface_albedo should, at least 
by default, apply to solar radiation.


Finally, "downwelling" is redundant here, since it is implicit in the 
definition of surface albedo. After these simplifying assumptions, we could use:
direct_surface_albedo
and
diffuse_surface_albedo.

8:
Yes, this the associated CMIP6 variable is the total incoming shortwave flux in 
bands, so a new name is not needed.

9 & 10
volume_extinction_coefficient_in_air_due_to_ambient_aerosol_particles and 
single_scattering_albedo_in_air_due_to_ambient_aerosol_particles: I agree.

11
aerasym: 
volume_spectral_asymmetry_factor_in_air_due_to_ambient_aerosol_particles
"asymmetry factor" and "backscatter fraction" appear to be two well defined 
terms. I'll check with Robert Pincus to see which one he wants.

Looking at this again, I'm concerned that the use of "due_to_" is not entirely 
correct here: both "asymmetry factor" and "backscatter fraction" are properties 
of the particles ... I don't think it is part of an additive collection of 
terms which the use of "due_to" appears to imply. Hence, accepting your 
comments about "volume" and "spectral", I suggest:
asymmetry_factor_of_ambient_aerosol_particles or 
backscatter_fraction_of_ambient_aerosol_particles

regards,
Martin


Alison Pamment - UKRI STFCalison.pamment at stfc.ac.uk 

Thu May 31 12:31:51 MDT 2018

  *   Previous message (by thread): [CF-metadata] Precipitation fractions for 
LS3MIP 
  *   Next message (by thread): [CF-metadata] Standard name table and 
standardized region list updated 

  *   Messages sorted by: [ date 
] [ 
thread 
] [ 
subject 
] [ 
author 
]



Dear All,

Standard names were proposed some time ago for CMIP6 RFMIP and some of the 
names received a small amount of discussion back in 2016. However, none of the 
names were published at that time. Three names were proposed for GeoMIP as long 
ago as 2015, but strangely, although I have a copy of the GeoMIP email (which 
was addressed to the mailing list) it seems never to have actually appeared on 
the list. The RFMIP and GeoMIP quantities are similar, so I will address both 
in this message. I would particularly like some advice on RFMIP proposals 6 - 
11.

GeoMIP

1. stratosphere_optical_thickness_due_to_ambient_aerosol_particles (1)
The same quantity was recently proposed for PMIP and added in Version 53 of the 
standard name table, so this one is done.

2. toa_outgoing_shortwave_flux_assuming_clear_sky_and_no_aerosol (Wm-2)
This is the same as RFMIP proposal 1 (see below), so I will deal with this one 
as part of the RFMIP request.

3. toa_outgoing_shortwave_flux_assuming_no_aerosol (W m-2)
This proposal is straight forward. We have one existing assuming_no_aerosol 
name, 
volume_attenuated_backwards_scattering_function_in_air_assuming_no_aerosol_or_cloud.
 The definition can be constructed from existing text:
'The abbreviation "toa" means top of 

Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP.

[Martin Juckes - UKRI STFC]

Dear Jonathan,


(1) downward flux of heat in rainfall


OK, I can see the problem. surface_downward_sensible_heat_flux is currently 
defined to be the downward flux of sensible heat associated with air motions. 
That doesn't look right to me. Rain clearly has sensible heat and clearly 
carries it downwards. "Sensible heat" is widely used synonym for thermal 
energy, so I don't think we can justify restricting it to apply only to the 
thermal energy of air.


I still think it is better to use "anomaly" ... it would not break anything and 
would make the term clearer.


(2) I can see your point about a lake. I was thinking of rivers, and at any 
point on the river the water is flowing from upstream to downstream of that 
point. A lake is a special case in that it is a flat area, so it is normal to 
speak of upstream and downstream areas relative to the lake. For a grid cell 
with complex sub-grid topography, I think it is more natural to talk about 
inward and outward flow.


regards,

Martin


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 12 June 2018 14:50
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP.

Dear Martin and Alison

> surface_downward_sensible_heat_flux_due_to_rainfall_temperature_anomaly
>
> The rainfall temperature anomaly is the temperature of the snow relative to 
> the zero Celsius. The sensible heat flux due the rainfall temperature anomaly 
> is the product of three terms: the rainfall mass flux, the specific heat 
> capacity of the rain and the temperature anomaly.

I following your reasoning and thanks for the explanation. I don't like
"temperature flux" either. (In oceanography, I don't like the concept itself,
because the zero of temperature is arbitrary, and a temperature flux tells
you nothing about heat convergence.) To me "sensible heat flux" doesn't seem
right for this quantity, because that term is always used for turbulent heat
fluxes in air. This is a bit different.  Also, "anomaly" isn't right, because
we use this to mean a difference from climatology. I would therefore favour
being more explicit, and more closely related to the description of the
proposers, which refers specifically to rainfall onto snow. What about
  heat_flux_into_surface_snow_due_to_rainfall_temperature

> 5. River in- and out-flow [2]

> inward_water_volume_transport_in_river_channel
> outward_water_volume_transport_in_river_channel

It's good to base them on existing names, but I don't follow why you think
from_upstream and to_downstream don't work. If we are thinking of a cell, or
in non-model terms some body of water like a lake, the inflow is necessarily
from upstream, and the outflow is to downstream. That's the way gravity works.
:-)

Best wishes

Jonathan

>
> 3.1 hfrsHeat transferred to snowpack by rainfall   [W m-2]
>
> I have heard back from Hyungjun Kim, and this term should represent the same 
> thermodynamic quantity as the variable hfrainds, which was in CMIP5 with 
> temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water.  The 
> definition of this CF term, which Alison has copied into the discussion 
> below, make it clear that it relates to the flux of sensible heat (i.e. 
> thermal energy) associated with the a temperature anomaly relative to zero 
> Celsius. The fact that it is not the full thermal energy of the rain drops, 
> but only an anomaly component evidently makes the naming harder. The phrase 
> "temperature flux" appears to come from some work by Stommel, who made use of 
> a related term, albeit with different units. I agree with Karl that it is not 
> a very helpful term here, and it would be even more unhelpful if we take it 
> out of the oceanography context and into a land snow term.
>
> Oceanographers refer to the "temperature anomaly relative to zero Celsius" as 
> "the temperature in units of degrees Celsius", which is obviously correct -- 
> up to a point, yet, in an obscure way, not quite right when transplanted into 
> the CF list and the mandated adoption of the UNIDATA interpretation of units. 
> Converting "emperature in units of degrees Celsius" to Kelvin gives a 
> different answer to converting "temperature anomaly relative to zero Celsius" 
> to Kelvin: here we want the latter, so it is important to be explicit that we 
> are talking about a temperature anomaly.
>
> The word "anomaly" is most often used in the CF standard names to refer to an 
> anomaly relative to climatology, but I think we can use it for an anomaly 
> relative to 0 degC -- unless there is a better word?
>
>
> Hence, I suggest:
>
> surface_downward_sensible_heat_flux_due_to_rainfall_temperature_anomaly
>
> The rainfall temperature anomaly is the temperature of the snow relative to 
> the zero Celsius. The sensible heat flux due the rainfall temperature anomaly 
> is the product of three terms: the rainfall mass flux, the specific heat 
> capacity of the rain and the temperature