Re: [CF-metadata] Suggestion for standard names for bottom current and due to tides and Stokes drift

[Jonathan Gregory]

Dear Fran

Thanks for this. I probably didn't notice before that this one
> sea_water_to_direction_due_to_tides
is like this one
> sea_water_to_direction_at_sea_floor
and therefore also would benefit from the insertion of "velocity".

Best wishes

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

[CF-metadata] Suggestion for standard names for bottom current and due to tides and Stokes drift

[Jonathan Gregory]

Dear Marcelo

Yes - your proposal is consistent and logical - sorry I didn't notice this
before. I would suggest we insert "velocity" in the existing names of
sea_water_to_direction
sea_water_from_direction
as well as your proposal. It's not essential, but it sounds clearer and better
to me. The other names with to/from_direction are wind and waves, which more
obviously refer to travelling phenomena.

Best wishes

Jonathan


- Forwarded message from Marcelo Andrioni  -

> Date: Tue, 12 Nov 2019 16:59:38 -0300
> From: Marcelo Andrioni 
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] Suggestion for standard names for bottom current and
>   due to tides and Stokes drift
> 
> Dear Jonathan, my suggestion of sea_water_from_direction_at_sea_floor
> was based on the "basic" standard name:
> sea_water_from_direction
> The phrase "from_direction" is used in the construction
> X_from_direction and indicates the direction from which the velocity
> vector of X is coming. The direction is a bearing in the usual
> geographical sense, measured positive clockwise from due north.
> 
> so that the only difference would be to add the suffix _at_sea_floor
> like it was done with:
> sea_water_potential_temperature
> sea_water_potential_temperature_at_sea_floor
> 
> Thank you.
> 
> Em ter., 12 de nov. de 2019 às 16:22,
>  escreveu:
> >
> > Send CF-metadata mailing list submissions to
> > cf-metadata@cgd.ucar.edu
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > or, via email, send a message with subject or body 'help' to
> > cf-metadata-requ...@cgd.ucar.edu
> >
> > You can reach the person managing the list at
> > cf-metadata-ow...@cgd.ucar.edu
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of CF-metadata digest..."
> >
> >
> > Today's Topics:
> >
> >1. Suggestion for standard names for bottom current and due to
> >   tides and Stokes drift (Jonathan Gregory)
> >2. Re: Suggestion for standard names for bottom current and due
> >   to tides and Stokes drift (Marcelo Andrioni)
> >
> >
> > --
> >
> > Message: 1
> > Date: Mon, 11 Nov 2019 18:00:27 +
> > From: Jonathan Gregory 
> > To: "cf-metadata@cgd.ucar.edu" 
> > Subject: [CF-metadata] Suggestion for standard names for bottom
> > current and due to tides and Stokes drift
> > Message-ID: <2019180025.ga8...@met.reading.ac.uk>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Dear Francesca and Marcelo
> >
> > I think that "velocity" ought to appear in this one:
> > > sea_water_to_direction_at_sea_floor
> > It's the velocity which has a direction.
> >
> > Best wishes
> >
> > Jonathan
> >
> > - Forwarded message from Francesca Eggleton - UKRI STFC 
> >  -
> >
> > > Date: Mon, 11 Nov 2019 17:29:31 +
> > > From: Francesca Eggleton - UKRI STFC 
> > > To: "cf-metadata@cgd.ucar.edu" 
> > > Subject: [CF-metadata] Suggestion for standard names for bottom current 
> > > and
> > >   due to tides and Stokes drift
> > >
> > > Dear Marcelo,
> > >
> > >
> > >
> > > Thank you for your proposals and apologies for the delay in responding. 
> > > As you may have seen in Alison's last email, I will be helping out with 
> > > the maintenance of the standard names.
> > >
> > >
> > >
> > > Thank you to Jonathan for comments on these proposals. They all look good 
> > > and seem to match what already exists. The two phrases which were 
> > > suggested as aliases, I believe to be new terms and have suggested a 
> > > reason why so please comment if you agree/disagree. The following text 
> > > will list each of the proposals, their units and descriptions 
> > > (constructed from similar terms to be in line with standard name 
> > > descriptions). Please let me know if there are any comments or further 
> > > changes to be made. If no comments are made in the next 7 days, these are 
> > > likely to be accepted in the next update.
> > >
> > > eastward_sea_water_velocity_at_sea_floor
> > > ms-1
> > > A velocity is a vector quantity. "Eastward" indicates a vector component 
> > > whi

[CF-metadata] Suggestion for standard names for bottom current and due to tides and Stokes drift

[Jonathan Gregory]

Dear Marcelo

These look fine to me, thanks. Just to be clear - you're *not* proposing
at_bottom, are you? I agree with you that at_sea_floor would be the right
phrase to use.

Best wishes

Jonathan

- Forwarded message from Marcelo Andrioni 
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Suggestion for standard names for bottom current and
due to tides and Stokes drift

Hello,

I would like to suggest the inclusion of standard names for u, v,
speed and direction for bottom current and due to tides and Stokes
drift:

An example of model output with bottom velocity is the HYCOM NCODA forecast:
https://tds.hycom.org/thredds/catalog/GLBv0.08/expt_93.0/data/forecasts/runs/catalog.html?dataset=GLBv0.08/expt_93.0/data/forecasts/runs/FMRC_RUN_2019-10-13T12:00:00Z
water_u_bottom (m/s) = Eastward Water Velocity =
eastward_sea_water_velocity_at_bottom
water_v_bottom (m/s) = Northward Water Velocity =
northward_sea_water_velocity_at_bottom

based on existing variables:
sea_water_potential_temperature_at_sea_floor
sea_water_temperature_at_sea_floor
sea_water_salinity_at_sea_floor
sea_water_pressure_at_sea_floor

my suggestion would be:
eastward_sea_water_velocity_at_sea_floor
northward_sea_water_velocity_at_sea_floor
sea_water_to_direction_at_sea_floor
sea_water_speed_at_sea_floor

An example of model output with currents due to tides and Stokes drift
is the Mercator Forecast:
http://marine.copernicus.eu/services-portfolio/access-to-products/?option=com_csw=details_id=GLOBAL_ANALYSIS_FORECAST_PHY_001_024

based on existing variables:
eastward_sea_water_velocity_assuming_no_tide
northward_sea_water_velocity_assuming_no_tide
ocean_vertical_momentum_diffusivity_due_to_tides
ocean_vertical_tracer_diffusivity_due_to_tides

my suggestion would be:
eastward_sea_water_velocity_due_to_tides
northward_sea_water_velocity_due_to_tides
sea_water_to_direction_due_to_tides
sea_water_speed_due_to_tides

Stokes drift is present in the current CF table with:
sea_surface_wave_stokes_drift_x_velocity
sea_surface_wave_stokes_drift_y_velocity
I think it could help to add
sea_surface_wave_stokes_drift_eastward_velocity
sea_surface_wave_stokes_drift_northward_velocity
as aliases to make it clear it is zonal and meridional currents, and
not just along the grid X and Y dimensions.

Thank you very much.
-- 
Marcelo Andrioni
marceloandri...@gmail.com
___
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] Question to Parametric Vertical Coordinates

[Jonathan Gregory]

Dear Daniel

> Does "Parametric Vertical Coordinates" mean that there is a mathematical
> function, which describes the relation between the relevant (auxiliary)
> coordinate variables and the parametric vertical coordinate?

In section 4.3.3, it means that the physical vertical coordinate z(k,j,i),
where i,j are indices of the horizontal dimensions and k of the vertical,
can be written as as a mathematical function
  z=f(V1(k)[,V2(k),...],H1([t,]j,i)[,H2([t,]j,i)...])
where V1,... depend only on level, and H1,H2,... depend only on horizontal
position (and perhaps on time). I think that describes all the cases of
Appendix D, but someone may correct me! The entries in App D describe the
physical vertical coordinate and how to compute it with the formula f.

> Speaking in terms of the example provided further below: Value of `depth` is
> a `f(time, lev, lat, lon)`, whereas `f` is a mathematical function with
> considerably less parameters than `depth` has values. Then `depth` is a
> parametric vertical coordinate.
> 
> Formulated the other way arond: Is `depth` NOT a parametric vertical
> coordinate if its values are somehow set by hand (by a human), calculated by
> some nested if-clause, or by some iterative procedure?
> 
> If `depth` is not a parametric vertical coordinate in this sense, am I
> allowed to use it in a CF-compliant file?

The depth variable in your example is a 4D auxiliary coordinate variable. It
is CF-compliant, but it's not a CF parametric vertical coordinate variable.

> Example:
> 
> ...
> int lev(lev):
>   lev:standard_name = "model_level_number" ;
>   lev:long_name = "model_level_number" ;
>   lev:positive = "down" ;
>   lev:units = "1" ;
> double depth(time, lev, lat, lon);
>   depth:long_name = "depth" ;
>   depth:positive = "down" ;
>   depth:standard_name = "depth" ;
>   depth:units = "m" ;
>   depth:axis = "Z" ;
> float some_data_variable(time, lev, lat, lon);
>   some_data_variable:standard_name = "some_standard_name" ;
>   some_data_variable:units = "some_unit" ;
>   some_data_variable:coordinates = "depth"

Best wishes

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

Re: [CF-metadata] New standard names for norm. direct radiation and atm. mass [SEC=UNCLASSIFIED]

[Jonathan Gregory]

Dear Alison

Thanks for your careful consideration. I have a couple of comments.

* I too think either shortwave_flux or solar_irradiance would be OK. Maybe
irradiance gets the purpose better for this name.

* I can recall a couple of reasons for the phrase surface_snow: (i) to
distinguish snow in the air from lying snow, (ii) to distinguish snow lying
on the ground from snow lying on the plant canopy. I think there may be a few
snow names which perhaps should be surface_snow e.g. for the grain size, but
in other cases it is evident from something else in the name that it means
lying snow, not falling snow. I don't think we need these distinctions for
rain, because we don't talk about rain lying on the ground, only when falling.
When it's on the ground, we call it something else, such surface_water, which
appears in three existing names, or a puddle! Snowfall and rainfall both mean
precipitation; those words refer in some way to the rate at which water is
impinging on the surface during the time interval of interest.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Tue, 1 Oct 2019 11:39:34 +
> From: Alison Pamment - UKRI STFC 
> To: "beate.ge...@hzg.de" , "CF-metadata
>   (cf-metadata@cgd.ucar.edu)" 
> Subject: Re: [CF-metadata] New standard names for norm. direct radiation and
>   atm. mass [SEC=UNCLASSIFIED]
> 
> Dear Beate and Ronny,
> 
> Thank you for your proposals and apologies for the delay in responding. Thank 
> you also to Jonathan and Ian for comments on these proposals. I have a number 
> of comments and questions of my own and would welcome discussion of the 
> issues raised.
> 
> 1. surface_normalized_direct_downwelling_shortwave_flux_in_air (W m-2)
> 'The surface called "surface" means the lower boundary of the atmosphere. 
> "Normalized_direct" radiation is radiation that has followed a direct path 
> from the sun to a plane perpendicular to the direction of the sun (in 
> contrast to the "direct" radiation, which falls on a plane horizontal at the 
> earth surface). 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 term "shortwave" means 
> shortwave radiation. In accordance with common usage in geophysical 
> disciplines, "flux" implies per unit area, called "flux density" in physics.'
> 
> I agree with Jonathan that it is better not to include "downwelling" in the 
> name because that suggests the flux is vertically downwards through the 
> atmosphere which does not appear to be the case here. I agree also that 
> "normalized" can have a number of meanings, although certainly we refer to 
> "normal" in the sense of "perpendicular to a surface" in existing names and 
> definitions.
> 
> Ian's suggestion of surface_direct_normal_downwelling_shortwave_flux_in_air 
> is close to the original proposal and uses similar terminology to the three 
> existing direct radiation names (which all refer to 'shortwave' rather than 
> 'solar'). If we take out the 'downwelling' that leaves us with 
> surface_direct_normal_shortwave_flux_in_air. Adding 'normal' to Jonathan's 
> suggestion would give us surface_direct_normal_solar_irradiance_in_air. So I 
> think it comes down to a choice between calling it a 'shortwave_flux' or a 
> 'solar_irradiance'. The former is closer to existing direct names, the latter 
> is apparently closer to WMO and energy industry terminology. I could live 
> with either and am happy to go with whatever is the majority view on this 
> point. I note that during a 2018 conversation about the definition of 
> existing solar_irradiance and shortwave names Stephane Tarot 
> (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/019809.html )pointed 
> us to a WMO reference which states that 'sol
 ar
>  ' and 'shortwave' mean the same thing in meteorological terminology. 
> 
> 2. atmosphere_mass_content_of_rainwater (kg m-2)
> ' "Content" indicates a quantity per unit area. The "atmosphere content" of a 
> quantity refers to the vertical integral from the surface to the top of the 
> atmosphere. For the content between specified levels in the atmosphere, 
> standard names including "content_of_atmosphere_layer" are used. "Rainwater" 
> refers to the precipitating part of liquid water in the atmosphere - the 
> cloud liquid water is excluded.'
> 
> Existing names for rain/rainfall quantities don't use 'rainwater' as a term 
> so I'd agree with Jonathan's suggestion of atmosphere_mass_content_of_rain. 
> However, I think this proposal and the accompanying one for 
> atmosphere_content_of_snow reveal a weakness in the definitions of some of 
> our existing names.
> 
> We have existing names such as rainfall_amount, convective_rainfall_amount 
> and stratiform_rainfall_amount which all have the same units (kg m-2) as the 
> proposed name. Are these intended to apply to rainfall that has 

[CF-metadata] distinction for Karl Taylor

[Jonathan Gregory]

Dear all

I am delighted to tell you (as you may already know) that Karl Taylor, who is
the chair of the CF governance panel and the CF committee, has been elected a
Fellow of the AGU. This is a richly deserved award, which recognises Karl's
immense contribution to climate science, both through his research, and through
his leadership of and contribution to international coordinated activities,
especially CMIP. An important part of this has been his work on CF. Karl
chaired the meeting nearly 20 years ago at which CF began. Thank you, Karl,
and well done.

Best wishes

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

[CF-metadata] PID to external description of Quality and Status states

[Jonathan Gregory]

Dear Daniel

I assume you mean a data variable which has strings describing quality or
status states, probably encoded with flag_values and flag_meanings. Would
the flag_meanings be meaningful to a human reading them? If so, you could
regard the file as self-describing. Self-describing doesn't have to mean
self-documenting, I would say. Standard names are self-explanatory to some
extent, and make the file self-describing, but they also have definitions
which aren't in the file, and papers in the peer-reviewed literature about
the quantities. If the flag_meanings are self-explanatory, I think that's OK,
but I'm not in favour of putting codes in the CF-netCDF file.

Best wishes

Jonathan

- Forwarded message from Daniel Neumann  -

> Date: Wed, 24 Jul 2019 14:45:33 +0200
> From: Daniel Neumann 
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] PID to external description of Quality and Status
>   states
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
>   Thunderbird/60.8.0
> 
> Dear list,
> 
> A CF-conformal NetCDF file should be as self-describing as possible.
> URIs/PIDs poitining to external data sources are problematic in this
> context. However, IDs pointing to external data sources were already
> discussed for taxa in the CF Trac Ticket #99 "Taxon Names and
> Identifiers" (https://cf-trac.llnl.gov/trac/ticket/99).
> 
> Let's assume we have a long description of quality control measures
> performed resulting in N possible quality states for a NetCDF
> variable. The full description could be part of a peer-reviewed
> paper or grey literature (with assigned PID). However, it is too
> long to be included in the attribute "description" of the
> quality/status flag variable. One solution would be to add a brief
> description of the quality states to the quality_flag/status_flag
> variable and point to the external full description via it's PID.
> 
> What is your opinion on this?
> 
> This is not a request for a feature but rather meant to collect some
> opinions on this topic. It is somehow related to the request of a
> global PID attribute in CF GitHub Issue 160 "Add attribute
> citation_id"
> (https://github.com/cf-convention/cf-conventions/issues/160).
> 
> Regards,
> Daniel
> 
> 
> -- 
> Dr. Daniel Neumann
> Abteilung Datenmanagement
> 
> Deutsches Klimarechenzentrum GmbH (DKRZ)
> Bundesstraße 45 a • D-20146 Hamburg • Germany
> 
> Phone: +49 40 460094-120
> Email: daniel.neum...@dkrz.de
> URL:  www.dkrz.de
> 
> Geschäftsführer: Prof. Dr. Thomas Ludwig
> Sitz der Gesellschaft: Hamburg
> Amtsgericht Hamburg HRB 39784
> 
> 



> ___
> 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] How to encode "not occurring" as distinct from "missing data"

[Jonathan Gregory]

Dear Lars

I think that using a flag_value would be a good CF way to do this. I am not
sure whether it's a good idea to choose a value which is outside the valid
range. That's not a problem for CF (that is, it's not prohibited), but maybe
it might not suit some software, which could object if it wasn't aware of CF
flag_values.

Best wishes

Jonathan


- Forwarded message from Bärring Lars  -

> Date: Fri, 19 Jul 2019 10:20:35 +
> From: Bärring Lars 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] How to encode "not occurring" as distinct from
>   "missing data"
> 
> Dear all,
> 
> We are considering how best to store data produced by some computation where 
> there has to be a distinction between missing input data (i.e. no input data 
> available) and "not occurring" (i.e. input data exists but the computation 
> did not result in a valid numeric value).
> 
> In practice, the situation is reasonably similar to what was discussed back 
> in 2017  (in the thread "Recording "day of year on which something happens") 
> where Jim Biard offered a solution 
> (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/019238.html).
> 
> We have considered his solution to use flag values outside the valid_range of 
> the data variable to indicate "no_occurrence". We have also considered to use 
> a separate quality variable with flag values to use as as a mask (combined 
> with _MissVal in the data variable).
> 
> In this work the following questions surfaced,
> 
> -- Is there any experience regarding how 'standard software' would handle 
> either of these alternatives, is one more generally accepted?
> 
> -- Is there any experience to guide us regarding which is better, or 
> generally more "in line with the CF Conventions"?
> 
> -- Is there another better approach that we have not thought of?
> 
> 
> Many thanks,
> Lars
> 

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

Re: [CF-metadata] Proposal to streamline CF Governance process

[Jonathan Gregory]

Here are the links again, with http:

http://www.met.rdg.ac.uk/~jonathan/CF_metadata/constitution.adoc
http://www.met.rdg.ac.uk/~jonathan/CF_metadata/constitution.html

Dear Daniel

> In discussions last year and in advance of the upcoming CF meeting at ESIP, 
> several colleagues have put forth the idea that the CF governance process 
> could be enhanced. I have put together a few concrete ideas of what to do 
> here in order to have a concrete item that we can point to, debate, disagree 
> on, etc. ...
> https://docs.google.com/document/d/1H9E1HKUzgmppLe091aVrHDeEbkPZXEML7_BUSc9Ddxs/edit?usp=sharing

Thanks for this initiative, for inviting comments on the documents and for our
exchange of emails (off-list).  Here I'm repeating a few things which I've
written in those emails, in preparation for the meeting next week. I hope to
participate remotely in some of that.

It seems to me that there are two distinct aspects of how CF works that you're
addressing: (1) the process of reaching decisions, (2) the panel and
committees. While they are both important, I would say that these are distinct.

(1) I am sure that everyone would like the decision-making process to be
efficient, and that we all know it sometimes is not, despite very thoughtful
and earnest debate. The migration of the conventions discussions (from trac)
and this email list (for standard name and other discussions) to GitHub may
streamline things a bit, but I feel the main reason why discussions are some-
times slow is the lack of impetus to reach a conclusion. More active moderation
may help, as discussed in github.com/cf-convention/cf-conventions/issues/151.
The current rules for making changes are at cfconventions.org/governance.html.

(2) On the same page there is a link to the CF governance document of 2006.
Appendix 2 of that document describes how the committees work. Those are the
rules we've been following, and I think they are mostly fine. I don't think we
should discard this document and start again. Instead, I think we should
consider whether modifications are needed. We should of course put it in GitHub
too, as you have suggested, so I've converted it to asciidoc, which is at
www.met.rdg.ac.uk/~jonathan/CF_metadata/constitution.adoc
and rendered at
www.met.rdg.ac.uk/~jonathan/CF_metadata/constitution.html
In preparing this I have also made some changes to bring it up-to-date with
current situation and adopting some of your suggestions, including:

* Remove what it says about the rules for making changes (your first issue),
since that belongs elsewhere.

* Include your paragraph about the role of the community.

* Add the annual meeting.

* Replace the two committees, which are already identical in fact, with one
committee that has two secretaries.

For comparison there's a link to the original version.

The main body for making decisions about CF is the community, via the GitHub
discussions, not the committee. The committee doesn't do most of the work,
although it has responsibilities to make sure things are decided. The only
formal role the committee has is that there's a requirement for two of them to
support any change. In that role, the committee is supposed to maintain
consistency and continuity in overseeing the development of CF. I think that it
is right for the CF governance panel to appoint the committee, and it's
intended to represent the community, not to be exclusive. The aim is for it to
be a group of activists who have shown themselves to have a sustained,
constructive and broad interest in the conventions as a whole. I think it would
be useful for the meeting next week to talk about how the committee could
better facilitate the community process.

Best wishes

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

[CF-metadata] Proposal to streamline CF Governance process

[Jonathan Gregory]

Dear Daniel

> In discussions last year and in advance of the upcoming CF meeting at ESIP, 
> several colleagues have put forth the idea that the CF governance process 
> could be enhanced. I have put together a few concrete ideas of what to do 
> here in order to have a concrete item that we can point to, debate, disagree 
> on, etc. ...
> https://docs.google.com/document/d/1H9E1HKUzgmppLe091aVrHDeEbkPZXEML7_BUSc9Ddxs/edit?usp=sharing

Thanks for this initiative, for inviting comments on the documents and for our
exchange of emails (off-list).  Here I'm repeating a few things which I've
written in those emails, in preparation for the meeting next week. I hope to
participate remotely in some of that.

It seems to me that there are two distinct aspects of how CF works that you're
addressing: (1) the process of reaching decisions, (2) the panel and
committees. While they are both important, I would say that these are distinct.

(1) I am sure that everyone would like the decision-making process to be
efficient, and that we all know it sometimes is not, despite very thoughtful
and earnest debate. The migration of the conventions discussions (from trac)
and this email list (for standard name and other discussions) to GitHub may
streamline things a bit, but I feel the main reason why discussions are some-
times slow is the lack of impetus to reach a conclusion. More active moderation
may help, as discussed in github.com/cf-convention/cf-conventions/issues/151.
The current rules for making changes are at cfconventions.org/governance.html.

(2) On the same page there is a link to the CF governance document of 2006.
Appendix 2 of that document describes how the committees work. Those are the
rules we've been following, and I think they are mostly fine. I don't think we
should discard this document and start again. Instead, I think we should
consider whether modifications are needed. We should of course put it in GitHub
too, as you have suggested, so I've converted it to asciidoc, which is at
www.met.rdg.ac.uk/~jonathan/CF_metadata/constitution.adoc
and rendered at
www.met.rdg.ac.uk/~jonathan/CF_metadata/constitution.html
In preparing this I have also made some changes to bring it up-to-date with
current situation and adopting some of your suggestions, including:

* Remove what it says about the rules for making changes (your first issue),
since that belongs elsewhere.

* Include your paragraph about the role of the community.

* Add the annual meeting.

* Replace the two committees, which are already identical in fact, with one
committee that has two secretaries.

For comparison there's a link to the original version.

The main body for making decisions about CF is the community, via the GitHub
discussions, not the committee. The committee doesn't do most of the work,
although it has responsibilities to make sure things are decided. The only
formal role the committee has is that there's a requirement for two of them to
support any change. In that role, the committee is supposed to maintain
consistency and continuity in overseeing the development of CF. I think that it
is right for the CF governance panel to appoint the committee, and it's
intended to represent the community, not to be exclusive. The aim is for it to
be a group of activists who have shown themselves to have a sustained,
constructive and broad interest in the conventions as a whole. I think it would
be useful for the meeting next week to talk about how the committee could
better facilitate the community process.

Best wishes

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

[Jonathan Gregory]

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 and auditing service may be provided 
> > by third parties. Such third parties can access information transmitted to, 
> > processed by and stored on NIWA's IT systems.
> >
> >
> > -Original Message-
> > From: CF-metadata  On Behalf Of Jonathan 
> > Gregory

[CF-metadata] Volume fraction standard names

[Jonathan Gregory]

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 - UKRI STFC 
>  -
> 
> > Date: Thu, 18 Apr 2019 15:55:39 +
> > From: Alison Pamment - UKRI STFC 
> > To: Martin Juckes - UKRI STFC , "Taylor, Karl E."
> > , "cf-metadata@cgd.ucar.edu"
> >

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

[Jonathan Gregory]

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 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 Analysis    Email: 
> 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 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.
> 
> Cheers
> 
> Jonathan
> ___
> CF-metadat

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

[Jonathan Gregory]

Dear Alison

Thanks - that's right.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Wed, 29 May 2019 14:44:17 +
> From: Alison Pamment - UKRI STFC 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] too many eddies in standard names
> 
> Dear Jonathan, Martin and Karl,
> 
> Martin's email about stresses at the liquid ocean surface reminded me that in 
> March we had also agreed to change the OMIP eddy_dianeutral_mixing names to 
> remove the word 'eddy' and amend the definitions accordingly:
> 
> 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_dianeutral_mixing
> 
> 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_dianeutral_mixing
> 
> 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_dianeutral_mixing.
> 
> The reference to eddies will be removed from the definitions and replaced 
> with the text suggested by Martin:
> ' "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.'
> 
> These changes are accepted for publication in the standard name table and 
> will be added in the June 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 Taylor, 
> Karl E.
> Sent: 06 March 2019 19:59
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] too many eddies in standard names
> 
> Sounds fine to me.
> Karl
> 
> On 3/6/19 6:19 AM, Jonathan Gregory wrote:
> > Dear Alison
> >
> > Yes, that's right, just the three dianeutral mixing terms. The names 
> > should have _eddy removed, and Martin's deletion of "eddy" from the 
> > definitions looks good to me. Sorry I didn't notice this before. Many 
> > thanks.
> >
> > Best wishes
> >
> > Jonathan
> >
> > - Forwarded message from Alison Pamment - UKRI STFC 
> >  -
> >
> >> Dear Jonathan, Martin, Karl,
> >>
> >> Thanks for discussing these names - I am always keen to make standard 
> >> names and their definitions as accurate as possible, including making 
> >> corrections if we don't get everything right in the original discussion. 
> >> If I understand correctly, it is now only the dianeutral mixing terms that 
> >> are  being revisited and the other eddy terms introduced for OMIP should 
> >> stay as originally agreed - is that right?
> >>
> >> I am not an expert in these quantities, but I am happy to update the 
> >> dianeutral mixing definitions as suggested by Martin if others are in 
> >> agreement.
> >>
> >> 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: 04 March 2019 19:36
> >> To: Jonathan Gregory ; 
> >> cf-metadata@cgd.ucar.edu
> >> Cc: stephen.griff...@noaa.gov
> >> Subject: Re: [CF-metadata] too many eddies in standard names
> >>
> >> Hello Jonathan,
> >>
> >>
> >> I agree that using "eddy" in terms which relate to vertical mixing is not 
> >> ideal. It is not entirely incorrect, b

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

[Jonathan Gregory]

Dear Martin

Thanks for explaining the use case. I agree that where flag_meanings is used
to encode a string-valued data variable, the permissible flag_values are those
which are allowed by data variable's standard name, if they are standardised.
I also agree that we should give guidance for the use of flag_values with
coordinate variables. I suggest something more general, such that coordinate
values which are flag_values are status codes that indicate that a numerical
coordinate value cannot be assigned to the cell, but the data is nonetheless
meaningful (in some way indicated by flag_meanings). For example (as I said
before) a possible application is for all coordinate values which are too small
or too large.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Thu, 16 May 2019 08:55:22 +
> From: Martin Juckes - UKRI STFC 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] Missing data bins in histograms
> 
> 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 Juc

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

[Jonathan Gregory]

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";
>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

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

[Jonathan Gregory]

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 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 coordinate -- but I'm not sure that that is adequate. Applications 
> and users are entitled to believe that a variable which has standard name 
> "height" really refers to height, without having to check all the auxiliary 
> coordinates to see if there is something there which modifies the meaning of 
> the variable. The standard name "height_bins" would signal that they must 
> look in the auxiliary coordinate.
> 
> 
> Do you agree with the necessity and appropriateness of the new name of 
> "bin_status_flag" which I have suggested for the auxiliary coordinate?
> 
> 
> regards,
> 
> Martin
> 
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 13 May 2019 18:00
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Missing data bins in histograms
> 
> Dear Martin
> 
> I agree that an alternative which would not require a change to the
> convention is to attach a string-valued aux coord variable. However, the
> flags are much more economical and seem natural, as you say.
> 
> As I said in my last email, I feel that it's better to keep the standard name
> as it is, despite the presence of a special value in it w

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

[Jonathan Gregory]

etadata/2016/date.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984>
>  [ thread 
> ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984>
>  [ subject 
> ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984>
>  [ author 
> ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984>
> 
> 
> 
> 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  cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
>  -
> 
> 
> 
> 
> 
> Date: Wed, 12 Oct 2016 14:58:11 -0400
> 
> 
> From: Jim Biard  cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> 
> 
> To: cf-metadata at 
> cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> 
> 
> 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 and peace,
> 
> 
> Jim
> 
> 
> On 10/12/16 1:30 PM, Jonathan Gregory wrote:
> 
> 
> Dear Jim
> 
> 
> That is an ingenious idea. I don't think the flag atts are currently allowed
> 
> 
> for coord variables, but they could be, I agree.
> 
> 
> Best wishes
> 
> 
> Jonathan
> 
> 
> - Forwarded message from Jim Biard  cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
>  -
> 
> 
> Date: Tue, 11 Oct 2016 14:39:56 -0400
> 
> 
> From: Jim Biard  cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> 
> 
> To: cf-metadata at 
> cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> 
> 
> 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
> 
> 
> Hi.
> 
> 
> Another approach could be to use flag_values and flag_meanings on
> 
> 
> the coordinate variable to indicate one or more special coordinate
> 
> 
> values that correspond to any number of "missing data" or "out of
> 
> 
> bounds" bins. These attributes aren't forbidden by CF, and
> 
> 
> everything should be fine as long as the coordinate variable remains
> 
> 
> monotonic.
> 
> 
> Grace and peace,
> 
> 
> Jim
> 
> 
> On 10/11/16 8:41 AM, martin.juckes at 
> stfc.ac.uk<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
>  wrote:
> 
> 
> Hello,
> 
> 
> the CF standard name list has two "histogram_ " entries, and in the CMIP6 
> data request we may need to add a third, a histogram_of_cloud_top_height. 
> Besides the standard name, we also need, for this new variable, a method of 
> encoding the "missing data" bin in the histogram. That is, the histogram 
> should record frequency in 16 data bins and one additional bin for the 
> frequency of missing data.
> 
> 
> Can we define a "missing_data_index" attribute for histogram variables, and 
> use this to indicate that the first bin in the array has this special 
> purpose. It might 

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

[Jonathan Gregory]

.m.gregory at reading.ac.uk 
> ><mailto:cf-metadata%40cgd.ucar.edu?Subject=Re%3A%20%5BCF-metadata%5D%20Missing%20data%20bins%20in%20histograms=%3C20161013094247.GF6219%40met.reading.ac.uk%3E><mailto:cf-metadata%40cgd.ucar.edu?Subject=Re%3A%20%5BCF-metadata%5D%20Missing%20data%20bins%20in%20histograms=%3C20161013094247.GF6219%40met.reading.ac.uk%3E>
> >Thu Oct 13 03:42:47 MDT 2016
> >
> >   *   Previous message (by thread): [CF-metadata] Missing data bins in 
> > histograms 
> > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/018983.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/018983.html>
> >   *   Next message (by thread): [CF-metadata] Usage of 
> > histogram_of_X_over_Z 
> > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/008836.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/008836.html>
> >   *   Messages sorted by: [ date 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984>
> >  [ thread 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984>
> >  [ subject 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984>
> >  [ author 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984>
> >
> >
> >
> >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  >cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> > -
> >
> >
> >
> >
> >
> >Date: Wed, 12 Oct 2016 14:58:11 -0400
> >
> >
> >From: Jim Biard  >cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> >
> >
> >To: cf-metadata at 
> >cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> >
> >
> >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 and peace,
> >
> >
> >Jim
> >
> >
> >On 10/12/16 1:30 PM, Jonathan Gregory wrote:
> >
> >
> >Dear Jim
> >
> >
> >That is an ingenious idea. I don't think the flag atts are currently allowed
> >
> >
> >for coord variables, but they could be, I agree.
> >
> >
> >Best wishes
> >
> >
> >Jonathan
> >
> >
> >- Forwarded message from Jim Biard  >cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> > -
> >
> >
> >Date: Tue, 11 Oct 2016 14:39:56 -0400
> >
> >
> >From: Jim Biard  >cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> >
> >
> >To: cf-metadata at 
> >cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> >
> >
> >Subject: Re: [CF-metadata] Missing data bins in histograms
> >
> >
> >User-Agent: Mozilla/5.0 (Macint

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

[Jonathan Gregory]

; >   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 
> ><mailto:cf-metadata%40cgd.ucar.edu?Subject=Re%3A%20%5BCF-metadata%5D%20Missing%20data%20bins%20in%20histograms=%3C20161013094247.GF6219%40met.reading.ac.uk%3E>
> >Thu Oct 13 03:42:47 MDT 2016
> >
> >   *   Previous message (by thread): [CF-metadata] Missing data bins in 
> > histograms 
> > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/018983.html>
> >   *   Next message (by thread): [CF-metadata] Usage of 
> > histogram_of_X_over_Z 
> > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/008836.html>
> >   *   Messages sorted by: [ date 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984> [ 
> > thread 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984> 
> > [ subject 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984>
> >  [ author 
> > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984>
> >
> >
> >
> >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  >cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> -
> >
> >
> >
> >>Date: Wed, 12 Oct 2016 14:58:11 -0400
> >>From: Jim Biard  >>cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> >>To: cf-metadata at 
> >>cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> >>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 and peace,
> >>Jim
> >>On 10/12/16 1:30 PM, Jonathan Gregory wrote:
> >>>Dear Jim
> >>>That is an ingenious idea. I don't think the flag atts are currently 
> >>>allowed
> >>>for coord variables, but they could be, I agree.
> >>>Best wishes
> >>>Jonathan
> >>>- Forwarded message from Jim Biard  >>>cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> -
> >>>>Date: Tue, 11 Oct 2016 14:39:56 -0400
> >>>>From: Jim Biard  >>>>cicsnc.org<http://mailm

[CF-metadata] order of product in standard name

[Jonathan Gregory]

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

Cheers

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

[Jonathan Gregory]

Dear Martin

Apologies for the Fwds that I put in last time. I have removed them this time.

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

Yes, I agree with that understanding.

I note that we already have the construction
covariance_of_X_and_Y[_over_Z]
in the guidelines, but we've not used it before. I think the over_Z is better
straight after the covariance, so it's clear what it applies to. Is that OK?
Would "wrt" be preferable to "over"?

Another issue which applies to other standard names containing X_and_Y, like
the ones you've been discussing with Alison, is which order to choose for X and
Y, since it's commutative. A possibility is to put them in alphabetical order,
but e.g. humidity comes before northward and after eastward. If one is a
vector component and one a scalar, we could choose a particular way round on
that basis, but not if both are scalars. Or we could permit both, with one
being an alias of the other, except that we don't usually introduce synonyms
deliberately - aliases are just to allow us to change our mind with backward
compatibility.

Best wishes

Jonathan

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

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

[Jonathan Gregory]

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

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

[Jonathan Gregory]

Actually it should be northward_wind, not northward_velocity.

- Forwarded message from Jonathan Gregory  -

> 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_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 h

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

[Jonathan Gregory]

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

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

[Jonathan Gregory]

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

Re: [CF-metadata] [cf-convention/cf-conventions] Incorporating the CF data model into the conventions (#159)

[Jonathan Gregory]

Dear David

I think the CF data model should be a separate document because it's
independent of netCDF, so it doesn't belong uniquely in a netCDF conventions
document. If CF was embodied in other formats, as we have often discussed
(JSON, zarr), the data model would apply equally to them as to netCDF.

I agree that the conformance document, which is specific to netCDF, could
be an appendix of the conventions document. In any case it should be in the
same repo as the conventions doc.

Best wishes

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

[Jonathan Gregory]

g else? Does anyone know what this name is 
> used for?
> 
> 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: 15 February 2019 09:21
> To: Taylor, Karl E. ; cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Putting the units in a CF standard name: 
> area_fraction
> 
> 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 tha

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

[Jonathan Gregory]

Dear all

Thanks for your contributions and support. We have taken note of reservations
expressed and will try to mitigate them. No-one has said they'd drop out if we
move to GitHub, while several have emphasised advantages, so I think that the
decision has been made to try it. David Hassell will work out the practical
details with Jeff Painter and Brian Eaton.

Business as usual will continue on this email list until further notice!

Best wishes

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

Re: [CF-metadata] New halocarbon standard name requests

[Jonathan Gregory]

Dear Roy

> You're right about hcc140a - I'd missed that because of the hyphen in the 
> IUPAC name trichloro-ethane. In my view the hyphen doesn't belong there (try 
> googling trichloro-ethane) if the IUPAC standard is strictly followed - 
> should be trichloroethane. If others agree maybe we should clean out the 
> hyphens from the definitions in a future update?

I agree that our chemical names in definitions should follow IUPAC.

Best wishes

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

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

[Jonathan Gregory]

Dear Martin

Yes, quite right, thanks. These instructions need to be updated.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Wed, 3 Apr 2019 11:35:38 +
> From: Martin Juckes - UKRI STFC 
> To: "Signell, Richard" , Daniel Lee
>   
> Cc: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] proposed migration of these discussions to GitHub
> 
> 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 k

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

[Jonathan Gregory]

Dear Mike and Klaus

Thanks for your emails. I understand your points, but it seems to me that what
we have proposed will not make life significantly more difficult. Specifically,

(1) We propose to have one discuss repository taking over all the functions
of the current email list, which is for everything except proposals to amend
the convention. Those are made in a different repository, which is taking over
from trac. So this is no change of organisation, just of platform. Up to now
we have not needed to split general queries from standard name proposals. We
could do that if there is a need, but since there hasn't been a need up to now
it is simplest to migrate to a new platform with no change of organisation.
Anyone with a query can start a GitHub issue to ask their question, and we will
make it clear that this is an expected use.

(2) We presently have two email lists, which is complicated, and neither of
them is a satisfactory arrangement for the future. The one I'm writing on now
(the UCAR email list) is taking significant effort to maintain (from Brian
Eaton - our thanks to him), so we need to move it, at least. The other one
(at LLNL) is OK for distributing GitHub postings but its archives cannot be
made public, so it would not be appropriate as a replacement for the UCAR
email list. Thus, if we want to retain an email list, we will need to start a
new one. It seems simpler not to do that, but to move to GitHub instead, since
the functionality is available.

This may not be your first choice, but is it satisfactory?

Is there anyone who is interested in CF but would not be willing or able to
use GitHub in future to raise questions that at present they would ask on this
email list?

Best wishes

Jonathan

- Forwarded message from Klaus Zimmermann  -

> Date: Fri, 5 Apr 2019 13:31:50 +0200
> From: Klaus Zimmermann 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] proposed migration of these discussions to GitHub
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
>   Thunderbird/60.6.1
>
> Dear Jonathan,
>
> for what it's worth, I am with Chris on this one.
>
> Imho a mailing list is the right format to shoot a question when you
> don't yet know exactly the approach (is it a feature request? a bug?
> just a clarification?) and who exactly you should ask. This way you
> reach all interested parties by the standard means of communication.
>
> An issue on github is great to preserve history and progress of, well,
> issues, such as bug reports and feature requests, typically with a
> rather small subset of interested people.

- Forwarded message from Mike Grant  -

> Date: Fri, 5 Apr 2019 11:43:35 +
> From: Mike Grant 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] proposed migration of these discussions to GitHub
> 
> [I'm personally happy with Github, but count as an interested person / long 
> time lurker!]
> 
> A lot of open source projects resolve this problem by splitting the 
> conversation into two mailing lists.  One is typically "-devel" for 
> developers (in this case, anyone working on the standard or proposing 
> changes) and one "-users" for people seeking help or wanting to report an 
> issue, but not wanting to get involved in the details.  Typically some/many 
> of the dev people sit on both lists and redirect misplaced conversations to 
> the correct list.
> 
> Perhaps a possible compromise here would be to move all the -devel 
> conversation onto Github in an organised fashion as proposed and create a 
> -users mailing list explicitly just for queries?
> 
> Cheers,
> 
> Mike.
> 
> -Original Message-
> >> From: Chris Barker - NOAA Federal 
> >> This list is also used to ask questions about how to best use the CF 
> >> conventions, not just changes to CF.
> >> And a list IS a good way to facilitate those conversations.
> >>
> >> I also think it might bd good to have a list that recurved 
> >> notifications of new discussion — though not every post!
> >>
> >> Still a listserve fan,
> >>
> >> -Chris
> >>
> >>
>  which is an administrative
>  complexity, especially as we currently have two different lists 
>  (for trac and email), which have to be kept consistent manually. 
>  Anyone can join GitHub for themselves and watch the CF repositories.
> 
>  Best wishes and thanks for your interest in CF
> 
>  Jonathan
> 
> 
>  To get a username on GitHub, go to https://github.com/ and sign up. 
>  This is free! Once you have a username, you can sign in.
> 
>  The issues on the CF conventions repository are at  
>  https://github.com/cf-convention/cf-conventions/issues
>  This shows the list of changes to 1.7 which are being discussed. 
> 
> Any email message from EUMETSAT is sent in good faith but shall neither be 
> binding nor construed as constituting a commitment by EUMETSAT, except where 
> provided for in a written agreement or contract or if 

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

[Jonathan Gregory]

Dear Chris

GitHub can fulfil the same function of discussion as the email list, through
discussion on an issue, which can be done entirely by email once the issue has
been opened on GitHub. GitHub will send the comments on the issues to the
LLNL CF email list, so that they will continued to be distributed by email for
existing subscribers. (Those who wish can unsubscribe from the email list and
watch the GitHub repositories instead.)

Does that sound all right to you?

Cheers

Jonathan

- Forwarded message from Chris Barker - NOAA Federal 
 -

> Date: Fri, 5 Apr 2019 03:37:32 +0200
> From: Chris Barker - NOAA Federal 
> To: Daniel Lee 
> Cc: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] proposed migration of these discussions to GitHub
> 
> I’m a big gitHub fan. But:
> 
> 
> >>
> >> * We won't have to maintain a CF email list,
> 
> This list is also used to ask questions about how to best use the CF
> conventions, not just changes to CF.
> 
> And a list IS a good way to facilitate those conversations.
> 
> I also think it might bd good to have a list that recurved
> notifications of new discussion — though not every post!
> 
> Still a listserve fan,
> 
> -Chris
> 
> 
> >> which is an administrative
> >> complexity, especially as we currently have two different lists (for trac 
> >> and
> >> email), which have to be kept consistent manually. Anyone can join GitHub
> >> for themselves and watch the CF repositories.
> >>
> >> Best wishes and thanks for your interest in CF
> >>
> >> Jonathan
> >>
> >>
> >> To get a username on GitHub, go to https://github.com/ and sign up. This is
> >> free! Once you have a username, you can sign in.
> >>
> >> The issues on the CF conventions repository are at
> >>  https://github.com/cf-convention/cf-conventions/issues
> >> This shows the list of changes to 1.7 which are being discussed. (NB the 
> >> name
> >> of this repository will probably change, to improve consistency, and this 
> >> is not
> >> the repository for the standard name discussions, which we have not yet
> >> created.) If you wanted to start a new issue, which is like a new email 
> >> thread
> >> e.g. for a standard name proposal, you would click the "New issue" button,
> >> and get from there to a web form where you type plain text, and then
> >> "Submit" it.
> >>
> >> To comment on an issue (like replying to an email thread) you click on the
> >> issue, go the bottom of the page, write in the box, and press "Comment".
> >>
> >> To receive emails containing comments on any of the issues contributed by
> >> others, you can "watch" the repository, by clicking on the drop-down menu
> >> labelled "Watch" at the top of the page, with an icon like an eye. When you
> >> receive such an email, you can reply to it and your reply will be posted 
> >> to the
> >> issue. (It tells you at the bottom of the email that you can do this, and 
> >> gives
> >> you the URL of the comment that's been sent in the the email in case you
> >> want to do it on GitHub.)
> >> ___
> >> CF-metadata mailing list
> >> CF-metadata@cgd.ucar.edu
> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> > Any email message from EUMETSAT is sent in good faith but shall neither be 
> > binding nor construed as constituting a commitment by EUMETSAT, except 
> > where provided for in a written agreement or contract or if explicitly 
> > stated in the email. Please note that any views or opinions presented in 
> > this email are solely those of the sender and do not necessarily represent 
> > those of EUMETSAT. This message and any attachments are intended for the 
> > sole use of the addressee(s) and may contain confidential and privileged 
> > information. Any unauthorised use, disclosure, dissemination or 
> > distribution (in whole or in part) of its contents is not permitted. If you 
> > received this message in error, please notify the sender and delete it from 
> > your system.
> > ___
> > 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] proposed migration of these discussions to GitHub

[Jonathan Gregory]

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 subscribers who would "leave" us because it's off-
putting to use GitHub. Please say if that is what you think before 8th April.

Among the advantages of making this change are that

* It would allow you to be selective, in that you could chose to be notified
about conventions but not standard names, or vice-versa, on GitHub. Of course,
we recommending watching both of them!

* We won't have to maintain a CF email list, which is an administrative
complexity, especially as we currently have two different lists (for trac and
email), which have to be kept consistent manually. Anyone can join GitHub for
themselves and watch the CF repositories.

Best wishes and thanks for your interest in CF

Jonathan


To get a username on GitHub, go to https://github.com/ and sign up. This is
free! Once you have a username, you can sign in.

The issues on the CF conventions repository are at
  https://github.com/cf-convention/cf-conventions/issues
This shows the list of changes to 1.7 which are being discussed. (NB the name
of this repository will probably change, to improve consistency, and this is
not the repository for the standard name discussions, which we have not yet
created.) If you wanted to start a new issue, which is like a new email thread
e.g. for a standard name proposal, you would click the "New issue" button, and
get from there to a web form where you type plain text, and then "Submit" it.

To comment on an issue (like replying to an email thread) you click on the
issue, go the bottom of the page, write in the box, and press "Comment".

To receive emails containing comments on any of the issues contributed by
others, you can "watch" the repository, by clicking on the drop-down menu
labelled "Watch" at the top of the page, with an icon like an eye. When you
receive such an email, 

[CF-metadata] Proposal for new standard names

[Jonathan Gregory]

Dear Bob

That looks logical to me. It is usual to provide standard names for different
choices of sign convention. Thanks.

Best wishes

Jonathan

- Forwarded message from Robert Fratantonio 
 -

> Date: Wed, 13 Mar 2019 21:04:37 +
> From: Robert Fratantonio 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] Proposal for new standard names
> user-agent: Microsoft-MacOutlook/10.10.4.181110
> 
> Hello,
> 
> 
> 
> Version 64 of the CF Standard Name Table has the following standard names:
> 
> direction_of_radial_vector_away_from_instrument
> 
> radial_sea_water_velocity_away_from_instrument
> 
> radial_velocity_of_scatterers_away_from_instrument
> 
> 
> 
> I'd like to propose the following new standard names to support these 
> standard names in the opposite direction convention:
> 
> 
> 
> direction_of_radial_vector_toward_instrument
> 
> units: degree
> 
> 
> 
> radial_sea_water_velocity_toward_instrument
> 
> units: m s-1
> 
> 
> 
> radial_velocity_of_scatterers_toward_instrument
> 
> units: m s-1
> 
> 
> 
> Many thanks for your consideration,
> 
> Bob
> 
> 
> 
> 
> Robert Fratantonio
> Software Engineer/Ocean Engineer
> RPS | North America
> 55 Village Square Drive
> South Kingstown RI 02879, USA
> T  +1 401 789 6224
> E  robert.fratanto...@rpsgroup.com
> rpsgroup.com
> 
> [signature_782530873]
> 
> 
> 
> 
> 
> This e-mail message and any attached file is the property of the sender and 
> is sent in confidence to the addressee only.
> 
> Internet communications are not secure and RPS is not responsible for their 
> abuse by third parties, any alteration or corruption in transmission or for 
> any loss or damage caused by a virus or by any other means.
> 
> RPS Group Plc, company number: 208 7786 (England). Registered office: 20 
> Western Avenue Milton Park Abingdon Oxfordshire OX14 4SH.
> 
> RPS Group Plc web link: http://www.rpsgroup.com

> ___
> 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] Where to find the latest cf-conventions?

[Jonathan Gregory]

Dear Bert

> Since the geometries discussion seems to have finalized, we would like to use 
> the Geometries described in the cf-conventions GitHub repository at
> https://github.com/cf-convention/cf-conventions/blob/master/ch07.adoc#geometries
> 
> However, I'm a bit confused about the formal status since the cf-conventions 
> main GitHub page
> https://github.com/cf-convention/cf-conventions
> states "This is an unofficial work-in-progress to show ...". Is this text 
> accurate or obsolete?

That text is out-of-date. That is the correct repository.

> And the latest 1.8 draft of the cf-conventions according
> http://cfconventions.org/cf-conventions/cf-conventions.html
> does not yet contain any section on the geometries. Should this be updated?

Yes. I assume that means it hasn't been merged. Once it has been, it will be
appear in the working draft of 1.8. 

We got a bit stuck with GitHub because of not having decided how to handle
notifications. However, we will make a decision about this very soon, and then
should be able to proceed with the move to GitHub from trac.

> Which one of the cf-conventions documents indicates the official latest draft?

The current version is 1.7. More than six months have passed since that was
released, so it is time for 1.8 to be released. We should do that soon.

Best wishes

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

[CF-metadata] parametric vertical coordinate standard_name confusion

[Jonathan Gregory]

Dear Karl

In answer to your other question, yes, the computed_standard_name should be
an attribute of the vertical coordinate variable, as well as the standard_name,
as shown in Example 4.3.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Thu, 7 Mar 2019 14:28:26 +
> From: Martin Juckes - UKRI STFC 
> To: "Taylor, Karl E." , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] parametric vertical coordinate standard_name
>   confusion
> 
> 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

- End forwarded message -
___
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

[Jonathan Gregory]

Dear Alison

Yes, that's right, just the three dianeutral mixing terms. The names should
have _eddy removed, and Martin's deletion of "eddy" from the definitions looks
good to me. Sorry I didn't notice this before. Many thanks.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> 
> Dear Jonathan, Martin, Karl,
> 
> Thanks for discussing these names - I am always keen to make standard names 
> and their definitions as accurate as possible, including making corrections 
> if we don't get everything right in the original discussion. If I understand 
> correctly, it is now only the dianeutral mixing terms that are  being 
> revisited and the other eddy terms introduced for OMIP should stay as 
> originally agreed - is that right?
> 
> I am not an expert in these quantities, but I am happy to update the 
> dianeutral mixing definitions as suggested by Martin if others are in 
> agreement.
> 
> 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: 04 March 2019 19:36
> To: Jonathan Gregory ; cf-metadata@cgd.ucar.edu
> Cc: stephen.griff...@noaa.gov
> Subject: Re: [CF-metadata] too many eddies in standard names
> 
> 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

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

[Jonathan Gregory]

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 +0000
> 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
> >
> > 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 &quo

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

[Jonathan Gregory]

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_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_p

[CF-metadata] too many eddies in standard names

[Jonathan Gregory]

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

Re: [CF-metadata] New standard name for 14CO2

[Jonathan Gregory]

ocarbon dating.'
> >
> > 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: Lowry, Roy K.  
> > Sent: 20 February 2019 19:30
> > To: Pamment, Alison (STFC,RAL,RALSP) ; 
> > cf-metadata@cgd.ucar.edu
> > Subject: Re: [CF-metadata] New standard name for 14CO2
> >
> > Dear Alison,
> >
> > I would suggest that if the reference standard isn't included in the 
> > Standard Name then I wouldn't put it into the definition. I don't like the 
> > idea of having narrower semantics in the definition compared to the name. 
> > How about putting a recommendation that the standard be specified in the 
> > long name into the definition?
> >
> > Cheers, Roy.
> >
> > I have now retired but will continue to be active through an Emeritus 
> > Fellowship using this e-mail address.
> >
> > 
> > From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of 
> > Alison Pamment - UKRI STFC <mailto:alison.pamm...@stfc.ac.uk>
> > Sent: 20 February 2019 16:40
> > To: mailto:cf-metadata@cgd.ucar.edu
> > Subject: Re: [CF-metadata] New standard name for 14CO2 
> >  
> > Dear Katherine, Roy, Jonathan, Daniel,
> >
> > Thank you all for the very clear and interesting discussion - I have 
> > learned a lot from reading all your comments and the various references. It 
> > seems that we are inching towards agreement on:
> > enrichment_of_14C_in_air_expressed_as_uppercase_delta_14C (Canonical unit: 
> > 1e-3).
> >
> > Certainly it is shorter and more readable if we don't include the reference 
> > standard in the name itself. I suggest that we include it in the definition 
> > for completeness, but leave it out of the name. In future, if someone were 
> > to propose a similar quantity based on a different standard we could add 
> > more detail into the names and turn the original one into an alias. 
> > However, the references I have looked at seem to indicate that the same 
> > international standard has been in use since the 1950s, so it isn't 
> > something that changes on a regular basis.
> >
> > Based on Roy's suggested definition, other comments in the discussion, and 
> > text used in the definitions of existing standard names, we would have 
> > something like the following:
> > 'Isotopic enrichment of 14C, often called d14C or delta14C (lower case 
> > delta), is used to calculate the fossil fuel contribution to atmospheric 
> > carbon dioxide using isotopic ratios of carbon. It is a parameterisation of 
> > the 14C/12C isotopic ratio in the sample with respect to the isotopic ratio 
> > in a reference standard, in this case the radiocarbon absolute reference 
> > standard, Oxalic Acid I. It is computed using the formula (((14C/12C)sample 
> > / (14C/12C)standard) - 1) * 1000. The quantity called D14C, or Delta14C 
> > (upper case delta) is d14C corrected for isotopic fractionation using the 
> > 13C/12C ratio as follows: D14C = d14C - 2(dC13 + 25)(1+d14C/1000). If the 
> > sample is enriched in 14C relative to the standard, then the data value is 
> > positive. Reference: Stuiver, M. and H.A. Polach, 1977, Discussion 
> > reporting of 14C data, Radiocarbon, Volume 19, No. 3, 355-363, doi: 
> > 10.1017/S003382223672.'
> >
> > Does that sound okay?
> >
> > 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.
> >
> >
> > Hi Jonathan and Roy, 
> >
> >
> > I do not feel there is need to mention the reference material. Oxalic Acid 
> > has been agreed upon as the primary reference material and any other 
> > reference materials are all traceable to the primary standards for 
> > radiocarbon analysis. 
> >
> > Thanks,
> 

Re: [CF-metadata] New standard name for 14CO2

[Jonathan Gregory]

Dear Roy

I went for "big" because it's shorter and a bit more amusing. If we have
"uppercase" it would also be OK - no need for _ in the middle of it, I think.

Yes, it would be good to hear an authoritative view on whether there is more
than one standard in use.

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Fri, 15 Feb 2019 15:24:06 +0000
> From: "Lowry, Roy K." 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] New standard name for 14CO2
> 
> Dear Jonathan,
> 
> I am almost happy with 'big_delta14C', but would prefer 'upper_case_delta14C'.
> 
> I still feel that unless explicitly told otherwise by a domain expert the 
> reference standard needs to be there. As I mentioned in a previous posting 
> there have been multiple 14C standards used over the past 40 years, although 
> I cannot say for certain whether more than one is in current use.
> 
> 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 Jonathan 
> Gregory 
> Sent: 15 February 2019 15:00
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard name for 14CO2
> 
> Dear all
> 
> Thank you for the clarifications. Actually I still do not understand what the
> normalisation does, but evidently it's a well-defined procedure.
> 
> I'm in favour of precision, of course, when there is a danger of ambiguity.
> Roy proposes
> 
>   
> enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_14C_in_carbon_dioxide_in_air_expressed_as_D14C
> 
> I would like to ask if we could make it
> 
>   enrichment_of_14C_in_carbon_dioxide_in_air_expressed_as_big_delta14C
> 
> That is: (a) Do we have to mention the reference standard? Katherine does not
> specify this. Is there more than one standard in use? If so, we do need to
> include it, I agree. (b) It seems clearer to me to spell out delta than to
> put just D. (c) I appreciate that the small-delta version is obsolete but we
> can't rule out it being needed sometime (or perhaps a similar distinction is
> in actual use with other isotopes?), and I think it would be unreliable to
> distinguish two standard names just because one had a small d where the other
> had a big D. If we ever need the small-delta version we can put small_delta.
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from "Robert M. Key"  -
> 
> > Date: Wed, 13 Feb 2019 14:31:58 +
> > From: "Robert M. Key" 
> > To: Katherine Pugsley 
> > CC: "Lowry, Roy K." , Jonathan Gregory
> >, "cf-metadata@cgd.ucar.edu"
> >
> > Subject: Re: [CF-metadata] New standard name for 14CO2
> >
> > What Katherine listed is correct.  I’m not going to try to use D/delta here 
> > because it so often changes from one computer to the next.
> >
> > Ever since Minze Stuiver’s paper came out, almost all ocean radiocarbon 
> > measurements have been reported as  D14C (o/oo). Oceanic 13C measurements 
> > on the other hand are reported in the standard d13C  ( eq. 2 in Katherine’s 
> > note with 13 instead of 14). In a few publications you do see D14C 
> > converted to atoms/KG, but that is only for inventories and similar because 
> > you can’t integrate permil units.
> >
> > Air measurements are, I think, not so consistent, but generally reported in 
> > the same way.
> > Minze Stuiver was a tree ring specialist, so I assume those data are also 
> > D14C (rather than d14C)
> >
> > In seawater the measurements are routinely made on dissolved inorganic 
> > carbon. These data are listed as the seawater D14C value without mention of 
> > inorganic component. This is equivalent to what Katherine listed in her 
> > first line.
> >
> > AMS techniques allow 14C measurements on the oceanic dissolved organic 
> > carbon (Ellen Druffel and a few others). These data are routinely listed as 
> > DO14C where here the D indicates dissolved rather than the previously used 
> > Delta (that is, Delta 14C on Dissolved Organic Carbon).
> >
> > bob
> >
> > On Feb 13, 2019, at 5:30 AM, Katherine Pugsley 
> >  wrote:
> >
> > The measurements I would like to report are . Here is the 
> > complete definition of how we have calculated .
> >
> > The isotopic composition can be expressed in delta values, in units of per 
> > mil (‰). The small delta (δ) is the isotopic ratio R (heavy C / light C) of 
&

Re: [CF-metadata] New standard name for 14CO2

[Jonathan Gregory]

Dear all

Thank you for the clarifications. Actually I still do not understand what the
normalisation does, but evidently it's a well-defined procedure.

I'm in favour of precision, of course, when there is a danger of ambiguity.
Roy proposes

  
enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_14C_in_carbon_dioxide_in_air_expressed_as_D14C

I would like to ask if we could make it

  enrichment_of_14C_in_carbon_dioxide_in_air_expressed_as_big_delta14C

That is: (a) Do we have to mention the reference standard? Katherine does not
specify this. Is there more than one standard in use? If so, we do need to
include it, I agree. (b) It seems clearer to me to spell out delta than to
put just D. (c) I appreciate that the small-delta version is obsolete but we
can't rule out it being needed sometime (or perhaps a similar distinction is
in actual use with other isotopes?), and I think it would be unreliable to
distinguish two standard names just because one had a small d where the other
had a big D. If we ever need the small-delta version we can put small_delta.

Best wishes

Jonathan

- Forwarded message from "Robert M. Key"  -

> Date: Wed, 13 Feb 2019 14:31:58 +
> From: "Robert M. Key" 
> To: Katherine Pugsley 
> CC: "Lowry, Roy K." , Jonathan Gregory
>   , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] New standard name for 14CO2
> 
> What Katherine listed is correct.  I’m not going to try to use D/delta here 
> because it so often changes from one computer to the next.
> 
> Ever since Minze Stuiver’s paper came out, almost all ocean radiocarbon 
> measurements have been reported as  D14C (o/oo). Oceanic 13C measurements on 
> the other hand are reported in the standard d13C  ( eq. 2 in Katherine’s note 
> with 13 instead of 14). In a few publications you do see D14C converted to 
> atoms/KG, but that is only for inventories and similar because you can’t 
> integrate permil units.
> 
> Air measurements are, I think, not so consistent, but generally reported in 
> the same way. 
> Minze Stuiver was a tree ring specialist, so I assume those data are also 
> D14C (rather than d14C)
> 
> In seawater the measurements are routinely made on dissolved inorganic 
> carbon. These data are listed as the seawater D14C value without mention of 
> inorganic component. This is equivalent to what Katherine listed in her first 
> line.
> 
> AMS techniques allow 14C measurements on the oceanic dissolved organic carbon 
> (Ellen Druffel and a few others). These data are routinely listed as DO14C 
> where here the D indicates dissolved rather than the previously used Delta 
> (that is, Delta 14C on Dissolved Organic Carbon).
> 
> bob
> 
> On Feb 13, 2019, at 5:30 AM, Katherine Pugsley 
>  wrote:
> 
> The measurements I would like to report are . Here is the 
> complete definition of how we have calculated .
>  
> The isotopic composition can be expressed in delta values, in units of per 
> mil (‰). The small delta (δ) is the isotopic ratio R (heavy C / light C) of a 
> sample relative to the isotope ratio of a standard substance (Equation 2, 
> Stuiver & Polach (1977)). 
> 
> (2)
> Here, 14C sample is the 14C content of sample, C sample is the carbon content 
> of sample, 14C std is the 14C content of standard and C standard is the 
> carbon content of standard. δ14C is used to calculate Δ14C.
> 14C can also be expressed as capital delta Δ14C (Equation 3, (Stuiver and 
> Polach, 1977)). The Δ14C is normalized to a δ13C value of -25 ‰, this is done 
> to account for fractionation. Fractionation effects discriminate against 14C 
> twice as much as for 13C (Stuiver and Polach, 1977). Normalising 14C 
> measurements to a common δ13C should, therefore, remove reservoir specific 
> differences caused by fractionation,
> 
>   (3)
> where δ14C is 14C signature [‰] and δ13C is 13C signature [‰].
> 
>  (4)
> 
> (5)
> Here, 13CO2 i is the abundance 13CO2 from sector i [mol mol-1] 
> 13CO2 i is 13CO2 signature sector i [‰], CO2 i = abundance CO2from sector i 
> [mol mol-1], 13R ref is the ratio of reference standard [(mol mol-1)/ (mol 
> mol-1)] and CO2 is the total abundance CO2 enhancement [mol mol-1] from 
> Equation 1.
> 
>   

Re: [CF-metadata] New standard name for 14CO2

[Jonathan Gregory]

; mailto:alison.pamm...@stfc.ac.uk>>
> Sent: 11 February 2019 12:49
> To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
> Subject: Re: [CF-metadata] New standard name for 14CO2
> 
> 
> 
> Dear Katherine, All,
> 
> Katherine and I had briefly discussed this name before it was proposed to the 
> mailing list - the suggestion of using mole_fraction was originally mine.  
> Evidently I had misunderstood the quantity in question, and it's clear from 
> the discussion so far that it wouldn't be appropriate to use mole_fraction in 
> this case. Thank you to Roy and Jonathan for clarifying this (and my 
> apologies to Katherine for misleading advice - I've not come across this 
> quantity before).
> 
> It does seem that we will need to introduce some new terminology into 
> standard names. Of Roy's two suggestions I prefer 
> enrichment_of_14C_in_carbon_dioxide_in_air. From Roy's explanation, it looks 
> like the quantity is in effect a ratio of ratios. While I appreciate that 
> this may be referred to as a 'delta' in the chemistry community, 'delta' is 
> often used as a mathematical symbol for calculating a difference or change, 
> so I feel that it's best avoided in the standard name.
> 
> Regarding the units of 'per mil', the canonical unit in the standard name 
> table would be written as '1e-6'.
> 
> Whichever terminology we choose, certainly we do need a clear definition - in 
> particular if the quantity is being calculated with reference to a particular 
> standard we should include that in the information. Katherine, please could 
> you give us some more details about exactly how this quantity is being 
> measured/calculated in your data?
> 
> 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-
> From: CF-metadata 
> mailto:cf-metadata-boun...@cgd.ucar.edu>> 
> On Behalf Of Jonathan Gregory
> Sent: 11 February 2019 04:57
> To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
> Subject: Re: [CF-metadata] New standard name for 14CO2
> 
> Dear all
> 
> I agree with Roy that delta-14C is not a mole fraction, but a way of 
> expressing the deviation of an isotopic ratio in a sample from a standard 
> isotopic ratio.
> The definition Roy gives for delta-13C is shown in several websites. I think 
> we need the precise definition of the quantity being proposed, because there 
> appear to be variou quantities with big and small delta and D, and maybe they 
> are all different, and would need distinct standard names. I think Roy is 
> right that we have not given standard names to such quantities before.
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from "Lowry, Roy K." 
> mailto:r...@bodc.ac.uk>> -
> 
> > Date: Fri, 8 Feb 2019 12:55:31 +
> > From: "Lowry, Roy K." mailto:r...@bodc.ac.uk>>
> > To: Katherine Pugsley 
> > mailto:katherine.pugs...@bristol.ac.uk>>,
> >"cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>" 
> > mailto:cf-metadata@cgd.ucar.edu>>
> > Subject: Re: [CF-metadata] New standard name for 14CO2
> >
> > I think that delta-14CO2 is not the same thing as the mole fraction. 
> > Rather, it is an expression of isotopic enrichment/depletion with respect 
> > to a standard. Whilst I have no experience of atmospheric 14C, I have come 
> > across delta notation a lot with other isotopes in geology and oceanography 
> > such as 13C and 18O. There, delta is an expression of the ratio of the 
> > target isotope to another isotope in the sample relative to some standard - 
> > ((sample 13C/12C ratio / standard 13C/12C ratio) - 1) * 1000 to give a 
> > result scaled to per mil. I presume that delta-14C is no different.
> >
> > I am unaware (i.e. I couldn't find) a precedent for delta values in CF 
> > Standard Names. The issue of describing these things has been addressed at 
> > length in the BODC parameter descriptions with almost 400 measurement 
> > descriptions. A typical example is:
> >
> > Enrichment with respect to Vienna Pee Dee Belemnite (VPDB) of
> > carbon-13 in carbonate in the sediment
> >
> > This particular example includes information on the specific standard used. 
> > Many do not because the information is often unavailable for older data.
> 

Re: [CF-metadata] New standard name for 14CO2

[Jonathan Gregory]

Dear all

I agree with Roy that delta-14C is not a mole fraction, but a way of expressing
the deviation of an isotopic ratio in a sample from a standard isotopic ratio.
The definition Roy gives for delta-13C is shown in several websites. I think
we need the precise definition of the quantity being proposed, because there
appear to be variou quantities with big and small delta and D, and maybe they
are all different, and would need distinct standard names. I think Roy is right
that we have not given standard names to such quantities before.

Best wishes

Jonathan
 
- Forwarded message from "Lowry, Roy K."  -

> Date: Fri, 8 Feb 2019 12:55:31 +
> From: "Lowry, Roy K." 
> To: Katherine Pugsley ,
>   "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] New standard name for 14CO2
> 
> I think that delta-14CO2 is not the same thing as the mole fraction. Rather, 
> it is an expression of isotopic enrichment/depletion with respect to a 
> standard. Whilst I have no experience of atmospheric 14C, I have come across 
> delta notation a lot with other isotopes in geology and oceanography such as 
> 13C and 18O. There, delta is an expression of the ratio of the target isotope 
> to another isotope in the sample relative to some standard - ((sample 13C/12C 
> ratio / standard 13C/12C ratio) - 1) * 1000 to give a result scaled to per 
> mil. I presume that delta-14C is no different.
> 
> I am unaware (i.e. I couldn't find) a precedent for delta values in CF 
> Standard Names. The issue of describing these things has been addressed at 
> length in the BODC parameter descriptions with almost 400 measurement 
> descriptions. A typical example is:
> 
> Enrichment with respect to Vienna Pee Dee Belemnite (VPDB) of carbon-13 in 
> carbonate in the sediment
> 
> This particular example includes information on the specific standard used. 
> Many do not because the information is often unavailable for older data.
> 
> A straw man alternative to Kate's proposal could be
> 
> enrichment_of_14C_in_carbon_dioxide_in_air
> 
> If information on the standard is available then that could be added as an 
> 'enrichment_with_respect_to_whatever' clause or the information could be 
> confined to the long name. The better solution depends upon the use case 
> (e.g. does it require inclusion of data where standard is unknown).
> 
> Another approach could be to adopt community vocabulary such as:
> 
> delta14C_in_carbon_dioxide_in_air
> 
> Others may have alternative suggestions.
> 
> I went for 'enrichment of x' in the BODC dictionary because it provides a 
> better fit to a normalised semantic model for mapping purposes. One only has 
> to include one 'enrichment' rather than a long list of 'deltas' in the 
> semantic element.
> 
> 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 Katherine 
> Pugsley 
> Sent: 08 February 2019 10:46
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] New standard name for 14CO2
> 
> 
> Dear All,
> 
> I'd like to request an addition to the standard name list for atmospheric 
> 14CO2 measurements. Here are the details of the proposed standard name.
> 
> Proposal for a new standard variable name
> 
> Name: mole_fraction_of_14C_dioxide_in_air
> 
> Canonical Units: 1
> 
> Description: Atmospheric 14CO2 measurements are reported in Δ14C notation 
> with units of per mil, the deviation from the absolute radiocarbon reference 
> standard. Δ14C is used to calculate fossil fuel CO2 content. The long name 
> will contain information that the variable is Δ14C.
> 
> 
> 
> Thanks,
> 
> Katherine
> 
> 
> 
> 
> This email and any attachments are intended solely for the use of the named 
> recipients. If you are not the intended recipient you must not use, disclose, 
> copy or distribute this email or any of its attachments and should notify the 
> sender immediately and delete this email from your system.
> UK Research and Innovation has taken every reasonable precaution to minimise 
> risk of this email or any attachments containing viruses or malware but the 
> recipient should carry out its own virus and malware checks before opening 
> the attachments. UK Research and Innovation does not accept any liability for 
> any losses or damages which the recipient may sustain due to presence of any 
> viruses.
> Opinions, conclusions or other information in this message and attachments 
> that are not related directly to UK Research and Innovation business are 
> solely those of the author and do not represent the views of UK Research and 
> Innovation.
> 

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

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

[Jonathan Gregory]

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

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

[Jonathan Gregory]

Dear all

While I sympathise with the problem, I too think that we shouldn't include
carbon in the units. In CF and the standard names we have always kept the
meaning of the quantity out of the units.

Clearly it's important for the data to be correct, but that applies to every-
thing requested by CMIP6. There are many things like this, I guess, where very
explicit guidance must be given about the quantity being requested to avoid
likely mistakes. If people are looking at the units and see kg instead of kgC,
then somewhere just next to the units (in the document they are looking at),
a note is needed to point out that because it's expressed_as_carbon it means
kg of C, not kg of stuff.

If a different phrase from expressed_as would be clearer in all the standard
names where we use it, so we can do a global substitution with aliases, as
Alison says, I think that would be fine.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Thu, 31 Jan 2019 13:07:26 +
> From: Alison Pamment - UKRI STFC 
> To: "r...@bodc.ac.uk" , "Jones, Chris D"
>   , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] CMIP6 Confusion regarding carbon flux units
> 
> Dear Chris, Martin, Roy,
> 
> I am sorry to hear that confusion is occurring regarding the carbon flux 
> names in C4MIP.  I certainly take Chris's point that it would be very 
> unfortunate if the data contain large errors due to misunderstanding of what 
> the variables should contain. However, I do agree with Martin that to change 
> the units of the names to 'kgC' would not be CF compliant because kgC is not 
> a unit in itself, whereas kg clearly is.
> 
> I think Roy is right that we need to try and address any confusion via the 
> standard name itself, rather than the units. I am getting the sense that 
> people aren't really understanding the "expressed_as" syntax, even though its 
> inclusion is specifically to address the difference between kg of C and kg of 
> CO2. I haven't had a lot of time to think about this, but my first reaction 
> would be to suggest changing the "expressed_as" names along the following 
> lines:
> surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon -> 
> surface_downward_mass_flux_of_carbon_contained_in_carbon_dioxide
> (just to give an example). For PMIP we did introduce names such as 
> precipitation_flux_containing_17O, so perhaps a similar approach could work 
> for C4MIP?
> 
> I think Daniel Neumann also raised some questions last year about the use of 
> "expressed_as" in relation to aerosol names. I confess to still not having 
> worked my way through the whole of that discussion (ironically because I was 
> so occupied with CMIP names last year), but perhaps this is the right time to 
> have a thorough review. It might lead to a lot of aliases being created, but 
> I would be supportive of doing that if it leads to improved clarity across 
> the board. We could start by addressing the names needed for C4MIP and work 
> through the others in batches. Chris, do you think improving the names would 
> help to address the problem?
> 
> 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: CF-metadata  On Behalf Of Lowry, Roy 
> K.
> Sent: 31 January 2019 12:34
> To: Jones, Chris D ; cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CMIP6 Confusion regarding carbon flux units
> 
> Dear Chris,
> 
> The embedding of semantics in units of measure is something I have fought 
> against for decades, largely because software agent AI algorithms are 
> unlikely to look for them there. Your suggestion is also something that would 
> never get past the guardians of UDUNITS. 
> 
> However, I can understand your frustration with vital semantics being buried 
> in the long name. Might a better solution be to include the necessary 
> semantics in the Standard Name? This has been done previously. For example:
> 
> surface_upward_mass_flux_of_carbon_dioxide_expressed_as_carbon_due_to_anthropogenic_land_use_or_land_cover_change_excluding_forestry_and_agricultural_products
> 
> sinking_mole_flux_of_calcite_expressed_as_carbon_in_sea_water
> 
> All in all a search for '%flux%expressed_as_carbon%' turned up 39 hits. There 
> are other examples that include phrases like 'expressed as 13C'.
> 
> If you are using Standard Names that do not include the 'expressed_as' clause 
> and no suitable alternatives with the clause exist then I would suggest that 
> you put in a new Standard Name request.
> 
> 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 

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

[Jonathan Gregory]

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] New reflectance standard names

[Jonathan Gregory]

Dear Jonathan

I'm not familiar with the Lambertian equivalent albedo. Probably this was
explained when we discussed it before and I have forgotten! However what you
write makes sense to me and the names look OK, apart from a minor point that
I think cosine_of would be better, like square_of, derivative_of and other
phrases naming functions.

I expect the previous discussion got overlooked accidentally. Sorry about that.
If no-one has any concerns now, Alison will consider the names for inclusion in
the next release of the table, in due course - she does this quite frequently.

Best wishes

Jonathan

- Forwarded message from Jonathan Wrotny - NOAA Affiliate 
 -

> Date: Thu, 24 Jan 2019 15:46:46 -0500
> From: Jonathan Wrotny - NOAA Affiliate 
> To: "Kennelly, Edward" , j.m.greg...@reading.ac.uk
> Cc: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] New reflectance standard names
> 
> Hello Jonathan Gregory (and CF board):
> 
> I work for the GOES-R satellite project, and I have been revisiting some
> proposed standard names that were previously submitted by people who work
> for GOES-R but the proposals did not reach the final stage to be approved
> as new or modified standard names.  One of these proposal was for two
> standard names submitted by Ted Kennelly:
> 
> “toa_lambertian_equivalent_albedo”
> 
> “Albedo is the ratio of the outgoing to the incoming power per unit area
> (irradiance). A coordinate variable can be used to specify the radiation
> wavelength or frequency. ‘toa’ means top of atmosphere.
> ‘lambertian_equivalent’ means the quantity is evaluated for a diffusely
> reflecting surface.”
> 
> canonical units = 1
> 
> 
> “toa_lambertian_equivalent_albedo_multiplied_by_cosine_solar_zenith_angle”
> 
> “Albedo is the ratio of the outgoing to the incoming power per unit area
> (irradiance). A coordinate variable can be used to specify the radiation
> wavelength or frequency. ‘toa’ means top of atmosphere.
> ‘lambertian_equivalent’ means the quantity is evaluated for a diffusely
> reflecting surface. ‘multiplied_by_cosine_solar_zenith_angle’ means that
> the quantity has normalized to remove the angular dependence of the
> incoming shortwave irradiance”
> 
> canonical units = 1
> 
> Based on my review of the CF metadata archive, there was some discussion
> about the two new proposed names between Ted and Jonathan Gregory and some
> agreement between them that they were valid proposed names, but I'm not
> seeing any additional comments be other members of the community.  These
> discussions were also back in 2013.
> 
> What else is required for these two proposed names to be approved?  Thank
> you.  Sincerely,
> 
> Jonathan

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

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

[Jonathan Gregory]

Dear Nan and Lars

What I said is what I've understood this name to mean, since I wrote it in the
first edition of the standard name table. However, unfortunately we have never
defined what we mean by "precipitation"! I believe it means water which falls
at the time specified or during the time interval specified, not the water
which has previously fallen. 

If it is a total since the last time the gauge was emptied, as Lars suggests,
you could still use this name, if you specified a time interval which begins
when the gauge reads zero. That would be the same for all of the later times of
measurement until it is next emptied, so each of these time intervals would
overlap, each one being longer than the one before. That's fine, though - it's
OK for cell bounds to overlap.

Best wishes

Jonathan

- Forwarded message from Bärring Lars  -

> Date: Thu, 24 Jan 2019 20:36:58 +
> From: Bärring Lars 
> To: "ngalbra...@whoi.edu" , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] Two [simple] questions
> 
> Nan ---
> 
> Just to better understand your setup: the data you are referring to comes 
> from a totalizer rain gauge, where the data may look like
> 
> day i, 321 mm
> day j, 321 mm
> day k, 333 mm 
> day l, 333 mm
> day k, 399 mm
> 
> and this is what you record , and store?
> 
> /Lars 
> 
> 
> Från: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] fr Nan Galbraith 
> [ngalbra...@whoi.edu]
> Skickat: den 24 januari 2019 19:42
> Till: cf-metadata@cgd.ucar.edu
> Ämne: Re: [CF-metadata] Two [simple] questions
> 
> I sincerely hope you're wrong about these standard names, Jonathan!
> 
> We include precip in our met files, and use the
> lwe_thickness_of_precipitation_amount
> standard name to report the actual level of water in a rain gauge.
> 
> It is NOT a rate of precip, which is calculated  (roughly, for rain
> gauges) by a first difference.
> 
> If the values in this variable were interpreted as a rate, it would be
> completely incorrect;  values
> that are unchanging convert to a rate of 0, no matter how high they may be.
> 
> Maybe I've been mis-using this standard name?
> 
> Thanks - Nan
> 
> 
> 
> 
> On 1/24/19 9:34 AM, Jonathan Gregory wrote:
> > Dear Lars
> >
> >> 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?
> > You can use whichever you prefer. They would also be distinguished by
> > cell_methods. The first is extensive in time, so it has cell_methods of sum,
> > the second is intensive and has cell_methods of mean.
> >
> >> 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) ?
> > I expect others have something useful to say about that.
> >
> > Best wishes
> >
> > Jonathan
> > ___
> > CF-metadata mailing list
> > CF-metadata@cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> 
> 
> --
> ***
> * Nan GalbraithInformation Systems Specialist *
> * Upper Ocean Processes GroupMail Stop 29 *
> * Woods Hole Oceanographic Institution*
> * Woods Hole, MA 02543 (508) 289-2444 *
> ***
> 
> 
> ___
> 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

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

[CF-metadata] Two [simple] questions

[Jonathan Gregory]

Dear Lars

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

You can use whichever you prefer. They would also be distinguished by
cell_methods. The first is extensive in time, so it has cell_methods of sum,
the second is intensive and has cell_methods of mean.

> 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) ?

I expect others have something useful to say about that.

Best wishes

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

Re: [CF-metadata] question about proper cell bounds for ocean_volume_transport_across_line

[Jonathan Gregory]

Dear Matthias

> While I can provide (scalar) lat/lon that would be something like the
> section mid-point, and proper cell_bounds with these, the result is that
> the user then knows a lat/lon box where my data are from. The user does
> not yet know which ones of the box vertices are my actual section
> endpoints (could be the NW-to-SE corner or SW-to-NE).

I agree with Jim that the new simple geometries convention (coming in the next
version of CF) would be suitable to draw the line in detail.

> 3. We amend the standard_name definition to clarify that when looking in
> the direction in which the line is sequentially defined in the lat/lon
> bounds, positive is considered to be 90 degrees to the left. I assume
> this would not only apply to my particular standard_name, but all of:
>   ocean_volume_transport_across_line
>   sea_ice_area_transport_across_line
>   sea_ice_transport_across_line
>   sea_water_transport_across_line
>   snow_transport_across_line_due_to_sea_ice_dynamics

Yes, that's a good idea. By "to the left" do you mean anticlockwise, when
viewed from above? That would be consistent with the definition of polygonal
cell bounds.

Best wishes

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

Re: [CF-metadata] question about proper cell bounds for ocean_volume_transport_across_line

[Jonathan Gregory]

Dear Matthias

> Recap: I have a time series of ocean volume transport (given in
> Sverdrup) across a line. The line has two end points, and the transport
> is computed over a specific depth range. I would like to represent this
> in a clever way in a netcdf file with CF conventions.
> 
> As far as variables go, I really only have two (happy to add more to
> e.g. contain the cell boundaries), and their standard_names are:
>time
>ocean_volume_transport_across_line
> 
> I know how to include bounds for the time such that I can show over how
> many days my data were averaged.

Yes, including a cell_methods of "mean" for time.

> I suppose I could figure out the depth range by including a single
> scalar for depth, with associated bounds, and having a "coordinates"
> attribute on my transport that points to the depth. Does this sound
> correct?

Yes, that would be right. The cell_methods for depth would be "sum".

> How about the two section endpoints? And when I have those, how would
> the user know which direction across that section is counted positive?

So far, the tranport across line has been used only with "named" sections. The
names of the sections haven't been standardised in CF, but there's a list of
them for CMIP6, defined by endpoints, in Griffies et al. 2016, Table J1,
doi:10.5194/gmd-9-3231-2016. The reason for using names is that the exact line
depends on the model, so matching the names facilitates model comparison. I
don't remember a discussion about how to specify them more quantitatively. I
think it would be reasonable to attach scalar latitude and longitude (like the
depth range) and use their bounds to specify the endpoints.

The standard name table doesn't mention the sign convention. We should have
defined that. Griffies et al. says it's positive for northwards and eastwards.
But what if the normal to the section is north-west or south-east? Do you have
any in those quandrants? We ought to generalise this.
 
Best wishes

Jonathan

> 
> Cheers, Matthias
> 
> 
> 
> On Tue, 2016-04-26 at 08:25 -0700, Matthias Lankhorst wrote:
> > Dear CF,
> > 
> > what is the proper way to define the shape and boundaries of an oceanic
> > section, for which I want to report the volume transport across that
> > section?
> > 
> > The use case is an irregular-shaped section like OSNAP
> > (http://www.o-snap.org/wp-content/uploads/2013/11/20160329_OSNAP_planeview.jpg),
> >  and the property to be reported is the seawater volume transport in a 
> > given depth range as a timeseries with this CF standard_name:
> > ocean_volume_transport_across_line
> > 
> > There needs to be some ancillary variable to say what the line
> > coordinates are, and I am not sure how to squeeze that into
> > "cell_bounds".
> > 
> > In addition, how about the lower limit vertically if this is the
> > seafloor? If the transports were to be everything below e.g. 1000 m,
> > would it be appropriate to state vertical cell bounds as 1000 to 5000 m,
> > even if the ocean is not 5000 m deep? I.e. is the user intelligent
> > enough to realize that "5000" really means "5000 m or the seafloor,
> > whichever is shallower"?
> > 
> > Thanks, Matthias
> > 
> > 
> 
> -- 
> ___
> 
>  Dr. Matthias Lankhorst
>  Scripps Institution of Oceanography
>  9500 Gilman Drive, Mail Code 0230
>  La Jolla, CA 92093-0230
>  USA
> 
>  Phone:  +1 858 822 5013
>  Fax:+1 858 534 9820
>  E-Mail: mlankho...@ucsd.edu
>  http://pordlabs.ucsd.edu/mlankhorst/
> 
> 
> ___
> 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

Re: [CF-metadata] Sea water temperature anomaly standard name

[Jonathan Gregory]

Dear Roy

It's also fine to discuss things on the email list. GitHub is replacing trac
as the platform for proposals to change the convention.

> I totally disagree with this statement, which was similar to the one I 
> received a couple of years ago.  The way names should be defined should be 
> based on what makes the most sense and is most consistent with present 
> practice  (such as how are climatologies defined  - to me anomalies are the 
> flip side of climatologies), not present day convenience.  At the present 
> time it may be easier,  but in the long-run it is asking for problems.

We could indicate that it was an anomaly by using a different attribute from
the standard_name attribute. I agree that would work, but putting it in the
standard name works equally well. It is usual, in ordinary language, to say
that a quantity is "sea surface temperature anomaly", for example. Since there
are only a few use-cases, it seems to me that there is not a strong argument
for adding a new mechanism to the convention, which is a greater complexity.
If the situation changed, then we could think again. We don't try too much to
anticipate what could go wrong before there is evidence that it will go wrong,
or is already going wrong, in the development of the CF convention, in order
to keep it as simple as possible.

Best wishes

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

Re: [CF-metadata] Sea water temperature anomaly standard name

[Jonathan Gregory]

Dear all

I too think it's fine to have a standard name for sea water temperature
anomaly. While I understand the concern about potentially huge numbers of
anomaly standard names, I don't think we need to deal with it by any other
means at present because very few have been proposed. There are just five at
present in the table.

Best wishes

Jonathan

- Forwarded message from John Graybeal  -

> 1) I support Simon/Roy’s request, it seems straightforward.
> 
> 2) Roy M, it would be good to get that discussion topic in a ticket, so we 
> can continue it there. But, I should warn you, I also went through that 
> argument about 12 years ago, and I can vouch that the CF metadata community 
> has been consistent over that time. I can’t remember the precise motivation, 
> but basically it is almost never the preferred model. (But at least one time, 
> when the observed thing was a taxonomic entity, I believe it was agreed to 
> adopt a plug-in approach.)  Perhaps now that SWEET is becoming a more 
> actively managed resource, and once CSDMS is more in the public realm, these 
> may serve as  patterns (and vocabulary sources) for using plug-ins in other 
> semantic models. 
> 
> john g.
> 
> 
> > On Dec 5, 2018, at 07:22, Roy Mendelssohn - NOAA Federal 
> >  wrote:
> > 
> > 
> > 
> >> On Dec 5, 2018, at 7:18 AM, Lowry, Roy K.  wrote:
> >> 
> >> I also feel that this could take some time and do not feel it would be 
> >> fair to block Simon's request until it is resolved. There are a number of 
> >> anomaly Standard Names and one more isn't going to make a great deal of 
> >> difference.
> > 
> > never meant to block Simon's request,  apologize if it was taken that way,  
> > I will look into the Github process.  It's  just that anomalies are common, 
> >  and we can have an endless series of new names,  or else base standard 
> > names that then have anomalies added to them,  which tells me what to do in 
> > every case.
> > 
> > -Roy M.
___
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

[Jonathan Gregory]

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

Re: [CF-metadata] ice_sheet/land_ice confusion

[Jonathan Gregory]

; 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 connectivity of air bubbles:  
> http://www.iceandclimate.nbi.ku.dk/research/drill_analysing/cutting_and_analysing_ice_cores/analysing_gasses/firn_zone/
>  ).
> 
> 
> Trying to understand this distinction takes us on a diversion away from your 
> original question, but it may help us to understand why people are interested 
> in areas of "snow" as distinct from "ice" (though we may not want to call it 
> "snow" in the end).
> 
> 
> The other problem is that piles of snow may contain some liquid water, and 
> the behaviour of this component will be reflected, to a limited extent, in 
> CMIP6 diagnostics. Accumulated layers of snow can be referred to as 
> "snowpack", but I'm not sure that the term is appropriate for snow which 
> might have fallen today and may be gone tomorrow. Perhaps something like 
> "surface_snow_layer"? Snow flakes and hail stones in the atmosphere may also 
> have some liquid water present, of course, but I'm not aware of anyone 
> wanting to refer to that liquid mass fraction in the standard names -- at the 
> surface, on the other hand, we do have a need to distinguish between frozen 
> and liquid parts of the snow layer.
> 
> 
> You ask why anyone would care about "all forms of solid water except snow" .. 
> and the answer is, I think, that, as far as CMIP6 is concerned, people only 
> care about the binary partition snow (i.e. surface snow layer) vs. ice (i.e. 
> solid ice). As far as I can tell, it is primarily yourself that is interested 
> in a comprehensive terminology that takes into account all possible forms of 
> frozen water ... with the best possible motivation of course, as we would lie 
> to have terminology which is robust and usable in the future.
> 
> 
> Coming back to your suggestion of using "ice_except_snow" to refer to parts 
> of the surface cryosphere which are not snow: I'm concerned that this does 
> not deal with the issue of liquid water in the surface snow layer, which 
> would not be a problem when we restrict attention to area types, but which 
> would become a problem as soon as we look at extending the terminology into 
> standard names. I'm also concerned that this approach is driven by a belief 
> in a specific interpretation of "snow" and "ice" which is far from universal 
> ... hence the long diversion above.

[CF-metadata] Decibel units in CF standard names

[Jonathan Gregory]

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

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

Re: [CF-metadata] ice_sheet/land_ice confusion

[Jonathan Gregory]

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 some lack of clarity in current naming conventions.
> 
> 
> regards,
> 
> Martin
> 
> 
> 
> 
> 
> 
> 
> From: CF-metadata  on behalf of Taylor, 
> Karl E. 
> Sent: 18 October 2018 19:27
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] ice_sheet/land_ice confusion
> 
> Dear all,
> 
> I tend to agree that ice_on_land will confuse many users, especially with 
> another surface type being named "land_ice".
> 
> I also think that incorporating "area type" into a standard_name can 
> sometimes lead to further complications (and potential confusion).  I'll 
> restrict my initial discussion here to "area type" used as an allowed value 
> for a variable with standard_name="area_type" or used in cell_methods.
> 
> I think "ice_and_snow_on_land" is fairly descriptive and is easy to 

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

[Jonathan Gregory]

Dear Martin

The definition of a calendar_month unit would also need rules about calendar
arithmetic e.g. What does 1 calendar_month since 31 January mean? What does
7.23 calendar_months since 31 January mean?

Best wishes

Jonathan


- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Thu, 18 Oct 2018 16:33:28 +
> From: Martin Juckes - UKRI STFC 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] 'months since' and 'years since' time units
> 
> 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 -

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

[Jonathan Gregory]

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.
> 
> Now, on to the discussion about months. Before my previous post I quickly 
> read through extensive exchange on this list back in 2011, so I really 
> appreciate David's comment that it is a complex subject. And that is the 
> reason for why I suggested is always month is always a year / 12. So, here is 
> an attempt to summarise the suggestion in a different way:
> 
> * standard and proleptic_gregorian calendars (status quo):
>   o the number of days in a month is not an integer
>   o same issue with respect to ordinary (western) world months.
> 
> * 365_day calendar:
>   + the number of seconds in a month would change from being "ill-defined 
> (?)" as 84600 * 365.242198781 / 12 = 2574957.50141, to more properly 84600 * 
> 365 / 12 = 2573250
>   o same issue with respect to ordinary (western) world months.
> 
> * 360_calendar:
>   + the number of seconds in a month would change from being "very 
> ill-defined (?)" as 84600 * 365.242198781 / 12 = 2574957.50141, to more 
> properly 84600 * 360 / 12 = 2538000
>   + the number of days in a month is an integer; 12 * 30 * 84600 = 2538000
>   + the definition of a month is consistent with what is expected in the 
> "360_day world"
>   o same issue with respect to ordinary (western) world months.
> 
> That is, even though the suggestion certainly do not solve everything (of 
> course!), the only argument against it, that I can see, is the work to tease 
> out the 

Re: [CF-metadata] ice_sheet/land_ice confusion

[Jonathan Gregory]

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 
> To: "CF-metadata (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
> 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: 18 October 2018 05:45
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] ice_sheet/land_ice confusion
> 
> Dear Alison
> 
> I agree that an alias mechanism would be better than abolishing something we 
> have introduced. Although it might sound inaccurate, "land ice" is a term 
> that is used in the literature to mean ice sheets and glaciers, rather than 
> all ice on land. It contrasts with sea ice, as has been remarked, 
> 
> I think that ice_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  

Re: [CF-metadata] ice_sheet/land_ice confusion

[Jonathan Gregory]

le. I have been 
> managing the area_types vocabulary following a parallel procedure to standard 
> names. It would be nice if we could think of a better term, so as to cause 
> less confusion with land_ice. We could then turn ice_on_land into an alias, 
> just as we would with a standard name.
> 
> I agree with Martin that Evan will probably need to request some new 
> area_types to work with his microwave data. Evan's suggestion of 
> land_without_snow_or_ice sounds like a good starting point. Similarly we can 
> discuss new area types for lakes with or without snow and/or ice. The key 
> thing with all of these, as with standard names, is to describe them clearly. 
> Where categories sound similar, or perhaps overlap, we need to be very clear 
> about what is included or excluded in each area_type.
> 
> 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 October 2018 12:44
> To: Taylor, Karl E. ; cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] ice_sheet/land_ice confusion
> 
> 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 
> > 

Re: [CF-metadata] ice_sheet/land_ice confusion

[Jonathan Gregory]

Dear Martin et al.

To be precise, we could say "in the Holocene" as the period during which the
those of Greenland and Antarctica are the only extant ice sheets. (Bring back
the old days, I say!)

If ice_on_land isn't needed by CMIP6, I think we should remove it, to avoid
confusion, unless anyone objects.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Wed, 17 Oct 2018 11:44:26 +
> From: Martin Juckes - UKRI STFC 
> To: "Taylor, Karl E." , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] ice_sheet/land_ice confusion
> 
> 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 

Re: [CF-metadata] ice_sheet/land_ice confusion

[Jonathan Gregory]

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 contrast to ice_on_land, which is comprehensively inclusive of
> all types of ice on land).
> 
> Also I think it should be clarified whether "snow" is considered to
> be "ice_on_land".  If not, I think the descriptive phrase "any other
> ice on a land surface" should be modified to read "any other ice on
> a land surface (except snow)".
> 
> Best regards,
> Karl
> 
> 
> 
> On 10/9/18 11:03 AM, Nowicki, Sophie (GSFC-6150) wrote:
> >Hi Karl,
> >
> >I am responding to your question about ice_sheet/land_ice (CF-metadata 
> >Digest, Message 2, Vol 186, Issue11), and deleted the other topics from the 
> >thread.
> >
> >ice_sheet would be the Greenland and Antarctic ice sheets. It contains both 
> >the grounded_ice_sheet (part of the ice sheet flowing over bedrock, and you 
> >are technically right that an ice sheet is a combination of many many 
> >glaciers) and floating_ice_shelf (the part that only flows on water).
> >
> >land_ice is much bigger as it includes the polar ice sheets, glaciers in 
> >non-polar regions (glaciers are considered small body of ice: for example in 
> >the Alps, or the US), and the small ice caps. The ice caps are also a large 
> >combinations of glaciers, but too small to be considered an ice sheets. For 
> >example the Svartissen Ice Cap in northern Norway.
> >
> >For ISMIP6, we are interested in ice_sheet, but some climate models may also 
> >include glaciers and ice caps (which ISMIP6 does not care about). Hence the 
> >use of both ice_sheet and land_ice in the ISMIP6 protocol (and I cant recall 
> >if land_ice was already present in CMIP5, but I think that it was).
> >
> >I don’t know the origin of ice_on_land.
> >
> >Jonathan: please help me make my answers less confusing...
> >
> >I hope that this helps,
> >
> >Sophie
> > Message: 2
> > Date: Tue, 9 Oct 2018 17:19:36 +
> > From: "Taylor, Karl E." 
> > To: "cf-metadata@cgd.ucar.edu" 
> > Subject: Re: [CF-metadata] ice_sheet / land_ice confusion
> > Message-ID: 
> > Content-Type: text/plain; charset="utf-8"
> > HI all,
> > Can any

[CF-metadata] standard names for sea surface roughness variables

[Jonathan Gregory]

I think this email may not have made it to the list, owing to an email
problem I've been having, so it's a few days late. Sorry.

Dear Andy

Thanks for your persistence and patience! Yes, I think are looking sensible
now, as you say.

> [Thinking even more long term, upwave/downwave slopes could be assigned 
> different values based on wave asymmetry, but lets not go there yet...]

... but it is sufficient reason for future-proofing I think.

I'm happy with all these except that I would suggest putting the component
immediately before "slope", which is what it most closely applies to i.e.

> sea_surface_wave_mean_square_x_slope
> sea_surface_wave_mean_square_y_slope
> sea_surface_mean_square_upwave_slope
> sea_surface_mean_square_crosswave_slope

This would be consistent with existing stdnames e.g.
  downward_x_stress_at_sea_ice_base
  land_ice_x_velocity

Best wishes

Jonathan

- Forwarded message from "Saulter, Andrew" 
 -

> Date: Fri, 5 Oct 2018 10:40:56 +
> From: "Saulter, Andrew" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] standard names for sea surface roughness variables
> 
> Dear Jonathon,
> 
> Thanks a lot, that is really helpful. Whilst I appreciate your point about 
> whether or not '_upwave/_downwave' are necessary if MSS is unsigned, I think 
> it wold still be useful to have this since the _mean_square_slope_*_direction 
> may well get compared with _wave_*_direction and/or _wind_*_direction. Since 
> and these latter follow a convention it is useful/necessary not to have any 
> ambiguity in how these are referenced. [Thinking even more long term, 
> upwave/downwave slopes could be assigned different values based on wave 
> asymmetry, but lets not go there yet...]
> 
> So, I think we have enough now to summarise the proposed new names and see 
> how we are doing...
> 
> Agreed so far (I think) from earlier mails:
> 
> charnock_coefficient_for_surface_roughness_length_for_momentum_in_air
> Units: 1
> Coefficient value, based on the Charnock (1955) empirical expression for 
> deriving surface_roughness_length_for_momentum_in_air  over the ocean. The 
> surface called "surface" means the lower boundary of the atmosphere.
>  
> sea_surface_wave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum.
> 
> sea_surface_wave_x_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "x" indicates that slope values are derived from vector 
> components along the grid x-axis.
> 
> sea_surface_wave_y_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "y" indicates that slope values are derived from vector 
> components along the grid y-axis.
> 
> Testing the new 'upwave' names:
> 
> sea_surface_upwave_mean_square_slope_direction
> Units: degree
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. " direction" is used to assign a directional axis along 
> which wave energy is travelling, with "upwave" used to indicate that this is 
> equivalent to a "from_direction".
> 
> sea_surface_upwave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "upwave" indicates that slope values are derived from 
> vector components along (parallel to) the axis from which waves are 
> travelling.
> 
> sea_surface_crosswave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "crosswave" ind

Re: [CF-metadata] standard names for sea surface roughness variables

[Jonathan Gregory]

Dear Andy

Those names look just right to me. Thanks very much. Have a good weekend
downing (or upping) excellent Cornish beer.

Cheers

Jonathan

On Fri, Oct 05, 2018 at 01:39:08PM +, Saulter, Andrew wrote:
> Date: Fri, 5 Oct 2018 13:39:08 +
> From: "Saulter, Andrew" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] standard names for sea surface roughness
>  variables
> 
> Dear Jonathon,
> 
> And thanks as always for your help with these. I agree re moving the 
> component names around. So, for completeness:
> 
> charnock_coefficient_for_surface_roughness_length_for_momentum_in_air
> Units: 1
> Coefficient value, based on the Charnock (1955) empirical expression for 
> deriving surface_roughness_length_for_momentum_in_air  over the ocean. The 
> surface called "surface" means the lower boundary of the atmosphere.
> 
> sea_surface_wave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum.
>  
> sea_surface_wave_mean_square_x_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "x" indicates that slope values are derived from vector 
> components along the grid x-axis.
>  
> sea_surface_wave_mean_square_y_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "y" indicates that slope values are derived from vector 
> components along the grid y-axis.
> 
> sea_surface_mean_square_upwave_slope_direction
> Units: degree
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "upwave_slope_direction" is used to assign a primary 
> directional axis along which wave energy associated with the slope 
> calculation is travelling; in this case "upwave" is equivalent to a 
> "from_direction".
>  
> sea_surface_mean_square upwave_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "upwave" indicates that slope values are derived from 
> vector components along (parallel to) the axis from which waves are 
> travelling.
>  
> sea_surface_mean_square_crosswave_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "crosswave" indicates that slope values are derived 
> from vector components across (normal to) the axis from which waves are 
> travelling.
> 
> Have a very good weekend
> Andy
> 
> 
> 
> -Original Message-
> From: CF-metadata  On Behalf Of Jonathan 
> Gregory
> Sent: 05 October 2018 14:25
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] standard names for sea surface roughness variables
> 
> Dear Andy
> 
> Thanks for your persistence and patience! Yes, I think are looking sensible 
> now, as you say.
> 
> > [Thinking even more long term, upwave/downwave slopes could be 
> > assigned different values based on wave asymmetry, but lets not go 
> > there yet...]
> 
> ... but it is sufficient reason for future-proofing I think.
> 
> I'm happy with all these except that I would suggest putting the component 
> immediately before "slope", which is what it most closely applies to i.e.
> 
> > sea_surface_wave_mean_square_x_slope
> > sea_surface_wave_mean_square_y_slope
> > sea_surface_mean_square_upwave_slope
> > sea_surface_mean_square_crosswave_slope
> 
> This would be consistent with existing stdnames e.g.
>   downward_x_stress_at_sea_ice_base
>   land_ice_x_velocity
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from "

[CF-metadata] standard names for sea surface roughness variables

[Jonathan Gregory]

Dear Andy

Thanks for your persistence and patience! Yes, I think are looking sensible
now, as you say.

> [Thinking even more long term, upwave/downwave slopes could be assigned 
> different values based on wave asymmetry, but lets not go there yet...]

... but it is sufficient reason for future-proofing I think.

I'm happy with all these except that I would suggest putting the component
immediately before "slope", which is what it most closely applies to i.e.

> sea_surface_wave_mean_square_x_slope
> sea_surface_wave_mean_square_y_slope
> sea_surface_mean_square_upwave_slope
> sea_surface_mean_square_crosswave_slope

This would be consistent with existing stdnames e.g.
  downward_x_stress_at_sea_ice_base
  land_ice_x_velocity

Best wishes

Jonathan

- Forwarded message from "Saulter, Andrew" 
 -

> Date: Fri, 5 Oct 2018 10:40:56 +
> From: "Saulter, Andrew" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] standard names for sea surface roughness variables
> 
> Dear Jonathon,
> 
> Thanks a lot, that is really helpful. Whilst I appreciate your point about 
> whether or not '_upwave/_downwave' are necessary if MSS is unsigned, I think 
> it wold still be useful to have this since the _mean_square_slope_*_direction 
> may well get compared with _wave_*_direction and/or _wind_*_direction. Since 
> and these latter follow a convention it is useful/necessary not to have any 
> ambiguity in how these are referenced. [Thinking even more long term, 
> upwave/downwave slopes could be assigned different values based on wave 
> asymmetry, but lets not go there yet...]
> 
> So, I think we have enough now to summarise the proposed new names and see 
> how we are doing...
> 
> Agreed so far (I think) from earlier mails:
> 
> charnock_coefficient_for_surface_roughness_length_for_momentum_in_air
> Units: 1
> Coefficient value, based on the Charnock (1955) empirical expression for 
> deriving surface_roughness_length_for_momentum_in_air  over the ocean. The 
> surface called "surface" means the lower boundary of the atmosphere.
>  
> sea_surface_wave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum.
> 
> sea_surface_wave_x_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "x" indicates that slope values are derived from vector 
> components along the grid x-axis.
> 
> sea_surface_wave_y_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "y" indicates that slope values are derived from vector 
> components along the grid y-axis.
> 
> Testing the new 'upwave' names:
> 
> sea_surface_upwave_mean_square_slope_direction
> Units: degree
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. " direction" is used to assign a directional axis along 
> which wave energy is travelling, with "upwave" used to indicate that this is 
> equivalent to a "from_direction".
> 
> sea_surface_upwave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "upwave" indicates that slope values are derived from 
> vector components along (parallel to) the axis from which waves are 
> travelling.
> 
> sea_surface_crosswave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. "crosswave" indicates that slope values are derived 
> from vector components across (normal to) the axis from which waves are 
> tra

Re: [CF-metadata] standard names for sea surface roughness variables

[Jonathan Gregory]

Dear Andy

Thanks. I think your suggestion of "upwind" is certainly clearer than "from"
(and "downwind" would be much better than "to"). Your middle options would be
fine.

> Parallel component: sea_surface_wave_mean_square_slope_along_upwave_direction
> Normal component: sea_surface_wave_mean_square_slope_across_upwave_direction

and your first options would be OK too, except I wonder if they'd be better as

> Parallel component: sea_surface_mean_square_upwave_slope
> Normal component: sea_surface_mean_square_crosswave_slope

since it's the slope which is along or across the direction, and I made
crosswave into one word like upwave, upward, eastward, etc. I think I'd
prefer these shorter ones myself.

But I still have a question about whether upwave and downwave need to be
distinguished anyway for a mean square slope. Isn't avg((dh/dx)^2) the same
regardless of the sign convention of x, if x is the wave direction? If it's
not, don't you have to say whether cross-wave is leftward or rightward,
correspondingly?

Best wishes

Jonathan


- Forwarded message from "Saulter, Andrew" 
 -

> Date: Mon, 1 Oct 2018 09:30:03 +
> From: "Saulter, Andrew" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] standard names for sea surface roughness variables
> 
> Good morning Jonathon,
> 
> Was nice to have a weekend's reflection on this, not least because I also got 
> a bit more feedback from some of my other waves colleagues (thanks Fabrice). 
> 
> A quick fundamental, the reason we need to have some form of 'along' and 
> 'across' follows the same argument as the 'spread' conversation. Basically, 
> wave energy in a given sea-state is not uni-directional, so we have a 
> dominant/mean direction that gets calculated, but there will be a component 
> of wave energy (with associated height, period, slope characteristics etc.) 
> that runs normal to this.
> 
> In terms of what the "direction" really is, the suggestion I've been given is 
> "upwave", i.e. a wave equivalent of "upwind" and, therefore, same as 
> "wave_from_direction" (correcting my initial suggestion of "to" in the 
> previous post).
> 
> This gives us a few choices for names I think?
> 
> Least verbose:
> Direction: sea_surface_upwave_mean_square_slope_direction / 
> sea_surface_wave_mean_square_slope_from_direction*
> Parallel component: sea_surface_upwave_mean_square_slope
> Normal component: sea_surface_cross_wave_mean_square_slope
> 
> More verbose (but perhaps more clear?):
> Direction: sea_surface_upwave_mean_square_slope_direction / 
> sea_surface_wave_mean_square_slope_from_direction*
> Parallel component: sea_surface_wave_mean_square_slope_along_upwave_direction
> Normal component: sea_surface_wave_mean_square_slope_across_upwave_direction
> 
> More consistent with existing names (but possibly least clear?):
> Direction: sea_surface_wave_mean_square_slope_from_direction
> Parallel component: sea_surface_wave_mean_square_slope_along_from_direction
> Normal component: sea_surface_wave_mean_square_slope_across_from_direction
> 
> * if we use _from_direction in conjunction with _upwave, then we need to add 
> some text to link the two terms in the standard name definition. 
> 
> Any of these make sense?
> Cheers
> Andy
> 
> PS. Devon is geographically 'up' from Cornwall - but definitely 'down' in 
> terms of the quality of pasties, clotted cream and beer
> 
> 
> 
> -Original Message-
> From: Jonathan Gregory  
> Sent: 28 September 2018 13:46
> To: Saulter, Andrew 
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] standard names for sea surface roughness variables
> 
> Dear Andy
> 
> > Re the direction of the _mean_square_slope, the parameter and calculation 
> > method from the wave spectrum is sufficiently different from that for 
> > _wave_[to/from]_direction that it should stand alone. There has already 
> > been a precedent set for this with waves, where different forms of 
> > parameter calculation from the spectrum are given their own names because 
> > there is not only a calculation difference but a different physical 
> > interpretation of each parameter (e.g. the various type of wave period). 
> 
> OK, fair enough. So you need sea_surface_wave_mean_square_slope_to_direction.
> 
> I'm still stuck with what this "direction" really is. Can we insert anything 
> else for ? in
>   sea_surface_wave_mean_square_slope_along_?_direction
>   sea_surface_wave_mean_square_slope_across_?_direction
> Apparently you want to quantify the mean square slope along and across the 
> direction of the mean square slope. Is tha

[CF-metadata] Fwd: Re: Spectral wave direction spread parameter

[Jonathan Gregory]

Dear Roy

That's fine - thanks. I had overlooked that it was already defined.

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Fri, 28 Sep 2018 14:05:06 +
> From: "Lowry, Roy K." 
> To: Jonathan Gregory , Rob Thomas
>   
> CC: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] Spectral wave direction spread parameter
> 
> Dear Jonathan,
> 
> 
> I seem to remember the 'what is spread' discussion coming up last time we 
> encountered wave directional spread Standard Names. The Standard Name 
> sea_surface_wave_directional_spread has the definition:
> 
> 
> Directional spread is the (one-sided) directional width within a given 
> sub-domain of the wave directional spectrum, S(t,x,y,f,theta) where t is 
> time, x and y are horizontal coordinates (such as longitude and latitude), f 
> is frequency and theta is direction. For a given mean wave (beam) direction 
> the quantity approximates half the root mean square width about the beam 
> axis, as derived either directly from circular moments or via the Fourier 
> components of the wave directional spectrum.
> 
> 
> This seems to have been omitted from Rob's definition, which should I think 
> read:
> 
> 
> The quantity with the Standard  Name 
> sea_surface_wave_directional_spread_at_variance_spectral_density_maximum is 
> the directional spread of the most energetic waves. Directional spread is the 
> (one-sided) directional width within a given sub-domain of the wave 
> directional spectrum, S(t,x,y,f,theta) where t is time, x and y are 
> horizontal coordinates (such as longitude and latitude), f is frequency and 
> theta is direction. For a given mean wave (beam) direction the quantity 
> approximates half the root mean square width about the beam axis, as derived 
> either directly from circular moments or via the Fourier components of the 
> wave directional spectrum.
> 
> 
> 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 Jonathan 
> Gregory 
> Sent: 28 September 2018 13:26
> To: Rob Thomas
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Spectral wave direction spread parameter
> 
> Dear Rob
> 
> From the responses it's clear we need a name for this. I'm a bit nervous about
> "spread", which sounds vague to me. Can you clarify it?
> 
> Best wishes and thanks
> 
> Jonathan
> 
> On Fri, Sep 28, 2018 at 07:47:51AM +, Rob Thomas wrote:
> > Date: Fri, 28 Sep 2018 07:47:51 +
> > From: Rob Thomas 
> > To: "cf-metadata@cgd.ucar.edu" 
> > Subject: [CF-metadata] Spectral wave direction spread parameter
> >
> > Hi,
> >
> >
> >
> > Please can I propose/request a new standard name for the list:
> > "sea_surface_wave_directional_spread_at_variance_spectral_density_maximum"
> >
> >
> >
> > The rationale for this request is that in assessing our mappings of 
> > spectral wave parameters to the CF standard names we have mapped "Peak 
> > Direction" (described as "Dirp Direction for waves at peak of wave energy 
> > spectrum from which the waves are coming") to 
> > "sea_surface_wave_from_direction_at_variance_spectral_density_maximum" with 
> > definition:
> >
> >
> > The quantity with standard name 
> > sea_surface_wave_from_direction_at_variance_spectral_density_maximum is the 
> > direction from which the most energetic waves are coming. The spectral peak 
> > is the most energetic wave in the total wave spectrum. The phrase 
> > "from_direction" is used in the construction X_from_direction and indicates 
> > the direction from which the velocity vector of X is coming. The direction 
> > is a bearing in the usual geographical sense, measured positive clockwise 
> > from due north. The wave directional spectrum can be written as a five 
> > dimensional function S(t,x,y,f,theta) where t is time, x and y are 
> > horizontal coordinates (such as longitude and latitude), f is frequency and 
> > theta is direction. S has the standard name 
> > sea_surface_wave_directional_variance_spectral_density. S can be integrated 
> > over direction to give S1= integral(S dtheta) and this quantity has the 
> > standard name sea_surface_wave_variance_spectral_density.
> >
> >
> >
> > It does not appear there is an appropriate partner term for Peak Spread 
> > (described as "Dsprp Directional spread of waves at peak of wave 

Re: [CF-metadata] standard names for sea surface roughness variables

[Jonathan Gregory]

Dear Andy

> Re the direction of the _mean_square_slope, the parameter and calculation 
> method from the wave spectrum is sufficiently different from that for 
> _wave_[to/from]_direction that it should stand alone. There has already been 
> a precedent set for this with waves, where different forms of parameter 
> calculation from the spectrum are given their own names because there is not 
> only a calculation difference but a different physical interpretation of each 
> parameter (e.g. the various type of wave period). 

OK, fair enough. So you need sea_surface_wave_mean_square_slope_to_direction.

I'm still stuck with what this "direction" really is. Can we insert anything
else for ? in
  sea_surface_wave_mean_square_slope_along_?_direction
  sea_surface_wave_mean_square_slope_across_?_direction
Apparently you want to quantify the mean square slope along and across the
direction of the mean square slope. Is that right? I'm not sure what it means.
Without the "mean square", I'd think that the slope normal to the direction of
the slope must be zero, but it must be more subtle than that in this case!

Is there really an ambiguity of to/from with a mean square slope? It seems to
me that it must be the same (unsigned) number regardless of whether you go
backwards or forwards on a particular direction.

Is Devon up or down from Cornwall?

Best wishes

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

Re: [CF-metadata] Spectral wave direction spread parameter

[Jonathan Gregory]

Dear Rob

>From the responses it's clear we need a name for this. I'm a bit nervous about
"spread", which sounds vague to me. Can you clarify it?

Best wishes and thanks

Jonathan

On Fri, Sep 28, 2018 at 07:47:51AM +, Rob Thomas wrote:
> Date: Fri, 28 Sep 2018 07:47:51 +
> From: Rob Thomas 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] Spectral wave direction spread parameter
> 
> Hi,
> 
> 
> 
> Please can I propose/request a new standard name for the list:
> "sea_surface_wave_directional_spread_at_variance_spectral_density_maximum"
> 
> 
> 
> The rationale for this request is that in assessing our mappings of spectral 
> wave parameters to the CF standard names we have mapped "Peak Direction" 
> (described as "Dirp Direction for waves at peak of wave energy spectrum from 
> which the waves are coming") to 
> "sea_surface_wave_from_direction_at_variance_spectral_density_maximum" with 
> definition:
> 
> 
> The quantity with standard name 
> sea_surface_wave_from_direction_at_variance_spectral_density_maximum is the 
> direction from which the most energetic waves are coming. The spectral peak 
> is the most energetic wave in the total wave spectrum. The phrase 
> "from_direction" is used in the construction X_from_direction and indicates 
> the direction from which the velocity vector of X is coming. The direction is 
> a bearing in the usual geographical sense, measured positive clockwise from 
> due north. The wave directional spectrum can be written as a five dimensional 
> function S(t,x,y,f,theta) where t is time, x and y are horizontal coordinates 
> (such as longitude and latitude), f is frequency and theta is direction. S 
> has the standard name sea_surface_wave_directional_variance_spectral_density. 
> S can be integrated over direction to give S1= integral(S dtheta) and this 
> quantity has the standard name sea_surface_wave_variance_spectral_density.
> 
> 
> 
> It does not appear there is an appropriate partner term for Peak Spread 
> (described as "Dsprp Directional spread of waves at peak of wave energy 
> spectrum") because the options currently available do not appear to tie in to 
> the peak wave energy spectrum/spectral peak information.
> 
> 
> 
> Kind regards,
> 
> Rob
> 
> 
> 
> Dr. Rob Thomas
> 
> Senior Data Analyst - European Data Management Projects Team Leader
> 
> 
> 
> Marine Institute, Rinville, Oranmore, County Galway, H91 R673, Ireland
> 
> Tel: (+)353 (0)91 387 409
> 
> Mob: (+)353 (0)87 952 3467
> 
> Email: rob.tho...@marine.ie
> 
> ORCID: -0001-6068-4924
> 
> Web: http://data.marine.ie/

> ___
> 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 sea surface roughness variables

[Jonathan Gregory]

Dear Andy

> In this case "dominant" (which infers a method of calculation) is not the 
> same as "primary" (which is used in the existing wave standard names to 
> denote ranking of swell components). However, I agree we could omit the 
> "dominant" to bring this more in line with other wave directions, and provide 
> metadata to determine the method of calculation elsewhere - that would enable 
> a more flexible approach

Good. I agree. In that case, do you still need a new standard name for the
direction of the slope? Maybe you could use the existing
  sea_surface_wave_to_direction
for this purpose?

> sea_surface_wave_mean_square_slope_parallel_to_direction
> sea_surface_wave_mean_square_slope_normal_to_direction

I agree that the "to" here could be misunderstood. That's not your fault, of
course, but due to our peculiar use of "to" as a sort of adjective!

> I guess an alternative would be to use _along/_across instead of 
> _parallel_to/_normal_to?

There are some existing names containing across_line, where "across" means
"normal to", so it would be consistent to use that word. There aren't any
existing names containing normal, perpendicular, along or parallel. I suggest

> sea_surface_wave_mean_square_slope_along_wave_to_direction
> sea_surface_wave_mean_square_slope_across_wave_to_direction

which might alleviate the ambiguity, perhaps? Or maybe we don't need to include
the "to" in any case for waves. Does the same ambiguity exist, when talking
about waves, as we have with winds being eastward or easterly etc.?

Best wishes

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

Re: [CF-metadata] New name: fugacity of CO2

[Jonathan Gregory]

Dear Paul, Jim, Roy

Thanks for the clarifications. Now I understand that fugacity is different from
partial pressure, so I agree it needs its own names.

Best wishes

Jonathan

- Forwarded message from "Halloran, Paul"  -

> Date: Wed, 26 Sep 2018 11:59:05 +
> From: "Halloran, Paul" 
> To: "cf-metadata@cgd.ucar.edu" 
> x-mailer: Apple Mail (2.3445.9.1)
> Subject: Re: [CF-metadata] New name: fugacity of CO2
> 
> Thanks very much Jim.
> 
> Just to clarify (in light of Jim’s second point), my argument around air-sea 
> CO2 flux which I put forward to support my suggestion that we include 
> fugacity is that an imprecise conversion from fugacity of CO2 to pCO2 to 
> allow one to submit data as a compliant netcdf (due to potentially not having 
> the the other required variables available at the correct frequency), while 
> likely to only result in small numerical errors could have bigger 
> implications if then used to calculate air-sea CO2 flux. 
> 
> Thanks,
> Paul
> 
> > Hi Paul, Roy, et al.,
> > 
> > A couple of points regarding fugacity.
> > 
> > 1) In the proposed definition of fugacity, the first sentence could be 
> > misunderstood.  I suggest changing it to the following:
> > 
> > The fugacity is the measured pressure (or partial pressure) of a real gas 
> > corrected for the intermolecular forces of that gas, which allows that 
> > corrected 
> > quantity to be treated like the pressure of an ideal gas in the ideal gas 
> > equation PV = nRT.
> > 
> > 2) The air-sea flux of a gas does not depend on its fugacity, only its 
> > partial 
> > pressure (i.e., in both the atmosphere and ocean).
> > 
> > Cheers,
> > 
> > Jim
> ___
> 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

Re: [CF-metadata] standard names for sea surface roughness variables

[Jonathan Gregory]

Dear Andy

> Re the _mean_square_slope, I was probably over-thinking it. I'd also be happy 
> to lose the magnitude part; i.e. sea_surface_wave_[xy]_mean_square_slope

OK - fine!

> Fabrice highlighted that in addition to the grid x-y reference frame, it a 
> number of users would wish to consider mean_square_slope in an along-across 
> axis reference frame, where the axis used is a variable in its own right 
> (e.g. a dominant slope direction derived from the wave spectrum, or estimated 
> from wind direction). My suspicion is that x-y really implies 'grid' and not 
> 'along-across', so that we would then need to additionally specify something 
> like:
> 
> Along: sea_surface_wave_mean_square_slope_parallel_to_dominant_direction
> Across: sea_surface_wave_mean_square_slope_normal_to_dominant_direction
> Directional variable: sea_surface_wave_mean_square_slope_dominant_to_direction

Yes, x and y are grid directions, so you are right, you need different names
for those directions. We have quite a lot of names for waves already with
"direction" but not including "dominant", so can we omit "dominant"? Or does
"dominant" mean the same as "primary" in such existing names?

Best wishes

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

[CF-metadata] New name: fugacity of CO2

[Jonathan Gregory]

Dear Paul

We already have a standard name of
partial_pressure_of_carbon_dioxide_in_sea_water
Is that the same thing?

Best wishes

Jonathan

- Forwarded message from "Halloran, Paul"  -

> Date: Thu, 20 Sep 2018 15:40:31 +
> From: "Halloran, Paul" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] New name: fugacity of CO2
> x-mailer: Apple Mail (2.3445.9.1)
> 
> Dear mailing list,
> 
> I would like to propose a new standard name: 
> ‘fugacity_of_carbon_dioxide_in_sea_water’
> Variable name: fCO2
> Units: μatm
> Definition: The fugacity of CO2 is its effective partial pressure.
> 
> Thanks for your consideration of this,
> Paul
> ___
> 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

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Alison

If it's necessary to have names for unsigned quantities because it's really
not known, then I agree we should, but I think we ought strongly to discourage
recording of data without a sign convention. Maybe we could introduce new
names (with the existing ones as aliases) that explicitly say "unknown sign"
in them, in some way, with definitions that say they shouldn't be used if the
sign is known.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Thu, 20 Sep 2018 14:59:51 +
> From: Alison Pamment - UKRI STFC 
> To: "r...@bodc.ac.uk" , "cf-metadata@cgd.ucar.edu"
>   , "ngalbra...@whoi.edu"
>   
> Subject: Re: [CF-metadata] Platform Heave
> 
> Dear Nan and Roy,
> 
> In fact I had neglected to consider the case when the sign is unknown or 
> unrecorded. I am used to thinking about model data, where the sign of a 
> quantity is always known, but I appreciate that things may be different in 
> the world of observations! Nan's suggestion of retaining the current names 
> and also adding the pairs of new signed names would cover all possibilities 
> and fits within the existing schema for the standard name table. (If we go 
> down this route then I think we should still create aliases for the existing 
> names to remove the word 'angle' for consistency with the new names).
> 
> As you both point out, the definitions could be written to cross-reference 
> the signed and unsigned names so that CF users are directed to the most 
> appropriate name for their data. The appropriate NVS mappings could certainly 
> also be created.
> 
> I agree with Roy that we should allow for signed (and unsigned) rates, again 
> with appropriate cross-references in the definitions.
> 
> Do others support the idea of having triplets of names in this way?
> 
> 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: CF-metadata  On Behalf Of Lowry, Roy 
> K.
> Sent: 20 September 2018 15:38
> To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
> Subject: Re: [CF-metadata] Platform Heave
> 
> Hi Nan,
> 
> My understanding is that Alison was proposing leaving the existing 
> pitch/roll/yaw/heave in place, but with a note in the definitions that 
> direction isn't specified. New direction-specific names would then be added 
> and linked to the existing names as aliases (in the CF XML) or NarrowMatch 
> mappings (in NVS). This requires a change in the definition of 'alias' in the 
> CF Convention, which seems to have strong support.
> 
> This is exactly what you want!
> 
> Regarding the heave rates, I don't agree. In my view, if the quantities are 
> explicitly signed then names for explicitly signed quantity rate vectors 
> should also be available.
> 
> 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 Nan 
> Galbraith 
> Sent: 20 September 2018 15:11
> To: mailto:cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave 
>  
> Thank you, Alison. This all looks good.
> 
> With regards to your last point, about the existing names 
> heave/yaw/pitch/roll  (and their rates),
> I'm not sure why we need to deprecate anything or even create these 
> aliases. There may be cases
> where the magnitude of e.g. heave is important, but doesn't really even 
> need to be signed - or
> can't be signed because the heave distance or rate is provided by an 
> instrument and the 'sense' of
> the heave is not included.
> 
> Can't we just leave the existing (unsigned) names as they are, adding a 
> sentence about using the
> direction-specific names when direction is known?
> 
> Also, do we need both platform_heave_rate_up and 
> platform_heave_rate_down, or is heave_rate
> sufficient? This also applies to most or all of the rates ... sorry I 
> haven't looked at all of them
> to check how many pairs could be combined.
> 
> Last, thanks for clarifying the issue of order of terms in the 
> definitions. When using the
> html search function and looking for the difference between say 
> platform_course and
> platform_orientation, it is *much* easier (for a human, at least) if the 
> definition of the
> quantity comes first. Not everyone uses the standard name table this 
> way, I know, but for
> those who do this is really helpful.
> 
> Thanks for bringing this together!
> 
> - Nan
> 
> 
> 
> On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
> >
> > Dear Alison,
> >
> >
> > Your proposal is a much better solution than deprecating the original 
> > Standard Name and so has full support of Gwen and I.
> >
> >
> > Cheers, Roy.
> >
> >
> > 

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear all

I agree in applauding the hard work and excellent results of Jim and others.
Thanks! I also agree with Alison's proposal to change the convention to allow
an alias to apply to more than one existing standard name.

Best wishes

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

[CF-metadata] standard names for sea surface roughness variables

[Jonathan Gregory]

Dear Andy

Thanks for these proposals.

> charnock_coefficient_for_surface_roughness_length_for_momentum_in_air
> sea_surface_wave_mean_square_slope

are consistent with existing names and look fine to me.

I don't quite understand these ones.
> magnitude_of_sea_surface_wave_[xy]_mean_square_slope
You are considering the slopes in the x- and y-directions separately i.e.
deta/dx and deta/y, where eta is sea surface height. Maybe _[xy]_slope would
be clearer, if that's right. If it's a mean square, it surely must be positive,
mustn't it? If so, I don't see why it needs magnitude_of.

Best wishes

Jonathan

- Forwarded message from "Saulter, Andrew" 
 -

> Date: Fri, 14 Sep 2018 12:20:57 +
> From: "Saulter, Andrew" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] standard names for sea surface roughness variables
> 
> Hello everyone, hope you are all well.
> 
> I'd like to propose some new standard names for variables relating to sea 
> surface roughness please. The v0 suggestions are:
> 
> charnock_coefficient_for_surface_roughness_length_for_momentum_in_air
> Units: 1
> Coefficient value, based on the Charnock (1955) empirical expression for 
> deriving surface_roughness_length_for_momentum_in_air  over the ocean. The 
> surface called "surface" means the lower boundary of the atmosphere.
> 
> [Not for description text, but see also 
> http://glossary.ametsoc.org/wiki/Charnock%27s_relation]
> 
> 
> sea_surface_wave_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum.
> 
> magnitude_of_sea_surface_wave_x_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. Magnitude of "x" indicates that slope values are 
> derived from vector components along the grid x-axis, with slope always 
> taking a positive value.
> 
> magnitude_of_sea_surface_wave_y_mean_square_slope
> Units: 1
> Wave slope describes an aspect of sea surface wave geometry related to sea 
> surface roughness. Mean square slope describes a derivation over multiple 
> waves within a sea-state, for example calculated from moments of the wave 
> directional spectrum. Magnitude of "y" indicates that slope values are 
> derived from vector components along the grid y-axis, with slope always 
> taking a positive value.
> 
> [My main concern with these latter variables, is the use of magnitude and 
> vector x/y descriptors. Hopefully the descriptive text explains this OK; 
> basically a negative slope makes no sense in the context in which the data 
> are derived and used, i.e. for surface roughness estimation]
> 
> Will look forward to the comments :)
> Cheers
> Andy
> 
> 
> Andy Saulter
> Surge, Waves and Metocean Projects Manager
> Met Office  FitzRoy Road  Exeter  Devon EX1 3PB
> Tel: +44 (0)1392 884703  Fax: +44 (0)1392 885681
> andrew.saul...@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


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

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Roy

OK, yes. I agree with that too! We should not provide standard names for there
is no use case yet. However, it's a good idea for foresee how this may be done,
so that a neat solution is readily available when the day comes.

Best wishes and thanks

Jonathan

On Wed, Sep 05, 2018 at 04:07:26PM +, Lowry, Roy K. wrote:
> Date: Wed, 5 Sep 2018 16:07:26 +
> From: "Lowry, Roy K." 
> To: Jonathan Gregory ,
>  "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] Platform Heave
> 
> Dear Jonathan,
> 
> 
> This isn't a desire to mandate, it's just an attempt to prevent the creation 
> of six unnecessary Standard Names for sign conventions based on my knowledge 
> and researches of oceanographic data that don't exist. Should anybody come up 
> with a single example of the opposite sign convention in heave/sway/surge 
> from any other domain then the additional Standard Names will obviously  need 
> setting up. Anybody know of any??? It also goes without saying the 'normal' 
> conventions should leave the door open - for example 'upward heave' leaves 
> the door open for a future 'downward heave'.
> 
> 
> This follows another principle of CF Standard  Names which is that Standard 
> Names should only set up when there is a demonstrable use case and not just 
> in case a use case arises.
> 
> 
> 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 Jonathan 
> Gregory 
> Sent: 05 September 2018 16:26
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
> 
> Dear Jim and Roy
> 
> In general, we want CF to be able to describe the datasets that users want to
> describe, rather than mandating particular choices. Projects that use CF can 
> do
> that, of course, like CMIP6 does, which prescribes the standard_names of the
> quantities to be submitted.
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from Jim Biard  -
> 
> > Date: Wed, 5 Sep 2018 09:32:37 -0400
> > From: Jim Biard 
> > To: "cf-metadata@cgd.ucar.edu" 
> > Subject: Re: [CF-metadata] Platform Heave
> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
> >Gecko/20100101 Thunderbird/52.9.1
> >
> > Roy,
> >
> >
> > Good point! However (of course there has to be a 'but'!), are we OK
> > with forcing people to modify their data to match our convention?
> > Are there other situations where a standard name requires a certain
> > representation? The existing datasets that people have mentioned are
> > history, but they are also indicative of different sign conventions
> > out there "in the wild".
> >
> >
> > Grace and peace,
> >
> >
> > Jim
> >
> >
> > On 9/5/18 4:22 AM, Lowry, Roy K. wrote:
> > >
> > >Dear Jim,
> > >
> > >
> > >I think maybe you're doing more work than necessary. I see the
> > >work falling into three parts.
> > >
> > >
> > >1) Revision of the definitions of heave/heave rate that are part
> > >of a new Standard Name that has yet to be accepted.
> > >
> > >
> > >2) Creation of new Standard Names for Ken for sway/sway rate and
> > >surge/surge rate
> > >
> > >
> > >3) Upgrade to the definitions of the existing Standard Names for
> > >pitch, roll and yaw.
> > >
> > >
> > >How about hard-wiring direction conventions for cases (1) and (2)
> > >- heave positive up, surge positive forwards and sway to match
> > >Ken's data sets? As these are new Standard Names they cannot be
> > >out in the wild with the opposite direction convention.
> > >
> > >
> > >We would then need to deprecate the three existing Standard Names
> > >and replace them with six new ones.
> > >
> > >
> > >One other thought that is occupying my mind is whether the
> > >rate parameters are scalars or vectors? Any thoughts?
> > >
> > >
> > >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 Jim Biard 
> > >*Sent:* 04 September 2018 16:36
> > >*To:* cf-metadata@cgd.ucar.edu
> &

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Jim and Roy

In general, we want CF to be able to describe the datasets that users want to
describe, rather than mandating particular choices. Projects that use CF can do
that, of course, like CMIP6 does, which prescribes the standard_names of the
quantities to be submitted.

Best wishes

Jonathan

- Forwarded message from Jim Biard  -

> Date: Wed, 5 Sep 2018 09:32:37 -0400
> From: Jim Biard 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
>   Gecko/20100101 Thunderbird/52.9.1
> 
> Roy,
> 
> 
> Good point! However (of course there has to be a 'but'!), are we OK
> with forcing people to modify their data to match our convention?
> Are there other situations where a standard name requires a certain
> representation? The existing datasets that people have mentioned are
> history, but they are also indicative of different sign conventions
> out there "in the wild".
> 
> 
> Grace and peace,
> 
> 
> Jim
> 
> 
> On 9/5/18 4:22 AM, Lowry, Roy K. wrote:
> >
> >Dear Jim,
> >
> >
> >I think maybe you're doing more work than necessary. I see the
> >work falling into three parts.
> >
> >
> >1) Revision of the definitions of heave/heave rate that are part
> >of a new Standard Name that has yet to be accepted.
> >
> >
> >2) Creation of new Standard Names for Ken for sway/sway rate and
> >surge/surge rate
> >
> >
> >3) Upgrade to the definitions of the existing Standard Names for
> >pitch, roll and yaw.
> >
> >
> >How about hard-wiring direction conventions for cases (1) and (2)
> >- heave positive up, surge positive forwards and sway to match
> >Ken's data sets? As these are new Standard Names they cannot be
> >out in the wild with the opposite direction convention.
> >
> >
> >We would then need to deprecate the three existing Standard Names
> >and replace them with six new ones.
> >
> >
> >One other thought that is occupying my mind is whether the
> >rate parameters are scalars or vectors? Any thoughts?
> >
> >
> >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 Jim Biard 
> >*Sent:* 04 September 2018 16:36
> >*To:* cf-metadata@cgd.ucar.edu
> >*Subject:* Re: [CF-metadata] Platform Heave
> >
> >Jonathan,
> >
> >Two out of three of Nan's "most intuitive" rotations (pitch and
> >yaw) are clockwise rather than anticlockwise if the unit vectors
> >are X-fore, Y-port, and Z-up, which form a right-hand coordinate
> >system. This is part of why you will see examples where the unit
> >vectors are defined as X-fore, Y-starboard, and Z-down. This
> >orientation of the unit vectors makes yaw to starboard, pitch up,
> >and roll starboard down all anticlockwise rotations, but it points
> >the Z unit vector down, which is, for most people, rather
> >counter-intuitive. And this is why we are trying to define things
> >in terms that don't require specification of unit vector
> >directions.
> >
> >I'm going to try to continue down that path and avoid calling out
> >clockwise/anticlockwise.
> >
> >Grace and peace,
> >
> >Jim
> >
> >
> >On 9/4/18 10:18 AM, Jonathan Gregory wrote:
> >>Dear Jim
> >>
> >>>If that's the general consensus, then we can go that general
> >>>direction. I'll prepare pairs of everything.
> >>Thank you for your flexibility.
> >>
> >>>Regarding Nan's suggestions for names - I'm not a "ship person" so
> >>>starboard and port are unfamiliar terms that I have to constantly
> >>>check myself on. I dislike putting them in the names. I don't see
> >>>them in regular use in the satellite domain. The same goes for bow
> >>>as far as usage outside of the ship domain. Airplanes have noses.
> >>>Satellites have ... I don't know if there is even a name, as there
> >>>is no need for a leading edge. I'll struggle to find something, and
> >>>then we can wrangle over it.
> >>I agree with you - it would be better to have something generic and self-
> >>explanatory, even if it diverges from familiar terminology.
> >>
> >>>I think the "most intuitive" way to represent the

[CF-metadata] Ocean content tendencies due to sedimentation -- sign ambiguity in CMIP usage

[Jonathan Gregory]

Dear Martin

Thanks for spotting this. I agree with your solution.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Wed, 5 Sep 2018 09:05:33 +
> From: Martin Juckes - UKRI STFC 
> To: "CF-metadata (cf-metadata@cgd.ucar.edu)" 
> Subject: [CF-metadata] Ocean content tendencies due to sedimentation -- sign
>   ambiguity in CMIP usage
> 
> 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

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

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Jim

> If that's the general consensus, then we can go that general
> direction. I'll prepare pairs of everything.

Thank you for your flexibility.

> Regarding Nan's suggestions for names - I'm not a "ship person" so
> starboard and port are unfamiliar terms that I have to constantly
> check myself on. I dislike putting them in the names. I don't see
> them in regular use in the satellite domain. The same goes for bow
> as far as usage outside of the ship domain. Airplanes have noses.
> Satellites have ... I don't know if there is even a name, as there
> is no need for a leading edge. I'll struggle to find something, and
> then we can wrangle over it.

I agree with you - it would be better to have something generic and self-
explanatory, even if it diverges from familiar terminology.

> I think the "most intuitive" way to represent the angles - and most
> consistent as well, in my view - is clockwise rotations around the
> unit vectors. This makes positive yaw to starboard, positive pitch
> nose up, and positive roll starboard up. But we are talking about
> having both signs represented in names, so I guess that is moot.

I agree with this too. For describing polygonal bounds, we say that the
vertices should be traversed anticlockwise as seen from above. That is a
positive direction of rotation around the vertical axis, since longitude-
latitude-upward is a right-handed coordinate system. I suppose this is the
yaw rotation - but is that the opposite sign from yours?

Best wishes

Jonathan

> 
> On 9/3/18 12:51 PM, Jonathan Gregory wrote:
> >Dear Roy and Nan
> >
> >I agree that if there are existing names whose sign convention is undefined
> >we can't retrospectively define it. I think those ones ought to be 
> >deprecated,
> >though, in favour of new ones with signs indicated.
> >
> >Best wishes
> >
> >Jonathan
> >
> >- Forwarded message from Nan Galbraith  -
> >
> >>Date: Sun, 02 Sep 2018 11:57:33 -0400
> >>From: Nan Galbraith 
> >>To: "Lowry, Roy K." 
> >>Cc: cf-metadata@cgd.ucar.edu
> >>Subject: Re: [CF-metadata] Platform Heave
> >>User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)
> >>
> >>I second Roy's suggestion; existing names have undefined directionality,
> >>and new names have explicit directions. This seems like the only way to
> >>move forward. If there's a difference of opinion on which direction
> >>should be in the new name, we can easily create a pair for each term.
> >>
> >>What would the explicit names be?  Some of the terms in the thread
> >>below use 'right' and 'left' where 'port' and 'starboard' might be
> >>more clear, since, as Roy points out, left and right can be taken
> >>as 'looking forwards from the platform or looking at the front of
> >>the platform.'
> >>
> >>I also agree that these are the most intuitive way to represent these
> >>angles/motions:
> >>>heave positive up
> >>>pitch positive bow up
> >>>yaw positive to starboard roll positive starboard side down
> >>Would the names be something like heave_up, pitch_bow_up, yaw_to_starboard,
> >>and roll_to_starboard? We do need to differentiate these from the exiting
> >>names.
> >>
> >>Regards - Nan
> >>
> >>Quoting "Lowry, Roy K." :
> >>
> >>>Dear Jim,
> >>>
> >>>
> >>>>From my researches into existing oceanographic data sets
> >>>>(SeaDataCloud holdings plus EU glider data projects), covering
> >>>>heave, pitch, roll and yaw. I haven't discovered a single
> >>>>deviation from the conventions:
> >>>
> >>>heave positive up
> >>>
> >>>Pitch positive bow/nose up
> >>>
> >>>yaw positive to starboard
> >>>
> >>>roll starboard side down
> >>>
> >>>
> >>>I have yet to find any data sets, other than those described by
> >>>Ken in these discussions, in my searches containing surge or sway.
> >>>
> >>>
> >>>The only ambiguity I have found in the wider domain of Google is
> >>>where the concept of 'positive clockwise' has been used without
> >>>specifying whether the observer is looking forwards from the
> >>>platform or looking at the front of the platform. This isn't
> >>>helped by the multitude of bidirectional vectors (arrows at each
> >>>end) in illustrative diagrams.
> >>>
> >>>
> >>>Might our l

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Roy and Nan

I agree that if there are existing names whose sign convention is undefined
we can't retrospectively define it. I think those ones ought to be deprecated,
though, in favour of new ones with signs indicated.

Best wishes

Jonathan

- Forwarded message from Nan Galbraith  -

> Date: Sun, 02 Sep 2018 11:57:33 -0400
> From: Nan Galbraith 
> To: "Lowry, Roy K." 
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)
> 
> I second Roy's suggestion; existing names have undefined directionality,
> and new names have explicit directions. This seems like the only way to
> move forward. If there's a difference of opinion on which direction
> should be in the new name, we can easily create a pair for each term.
> 
> What would the explicit names be?  Some of the terms in the thread
> below use 'right' and 'left' where 'port' and 'starboard' might be
> more clear, since, as Roy points out, left and right can be taken
> as 'looking forwards from the platform or looking at the front of
> the platform.'
> 
> I also agree that these are the most intuitive way to represent these
> angles/motions:
> >heave positive up
> >pitch positive bow up
> >yaw positive to starboard roll positive starboard side down
> 
> Would the names be something like heave_up, pitch_bow_up, yaw_to_starboard,
> and roll_to_starboard? We do need to differentiate these from the exiting
> names.
> 
> Regards - Nan
> 
> Quoting "Lowry, Roy K." :
> 
> >Dear Jim,
> >
> >
> >>From my researches into existing oceanographic data sets
> >>(SeaDataCloud holdings plus EU glider data projects), covering
> >>heave, pitch, roll and yaw. I haven't discovered a single
> >>deviation from the conventions:
> >
> >
> >heave positive up
> >
> >Pitch positive bow/nose up
> >
> >yaw positive to starboard
> >
> >roll starboard side down
> >
> >
> >I have yet to find any data sets, other than those described by
> >Ken in these discussions, in my searches containing surge or sway.
> >
> >
> >The only ambiguity I have found in the wider domain of Google is
> >where the concept of 'positive clockwise' has been used without
> >specifying whether the observer is looking forwards from the
> >platform or looking at the front of the platform. This isn't
> >helped by the multitude of bidirectional vectors (arrows at each
> >end) in illustrative diagrams.
> >
> >
> >Might our lives be made easier if we adopted a set of conventions,
> >state them explicitly in the Standard Names as Jonathan suggests
> >leaving room in the unlikely - in my view at least - event of
> >Standard Names for the opposite convention being required?
> >
> >
> >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
> >Jim Biard 
> >Sent: 31 August 2018 14:38
> >To: cf-metadata@cgd.ucar.edu
> >Subject: Re: [CF-metadata] Platform Heave
> >
> >
> >Jonathan,
> >
> >That's only part of the issue. Here are the issues as I see them.
> >
> >  *   There is no single sign convention being followed in
> >existing datasets "in the wild".
> >  *   There is a long-standing convention for vertical coordinates
> >using the attribute positive rather than having pairs of standard
> >names for height_positive_up, height_positive_down, etc. The
> >suggested solution is corollary, and the positive attribute could
> >be used instead of adding a new attribute named direction with a
> >suitable expansion of possible valid values.
> >  *   In order to cover all bases, we'd need three versions for
> >each standard name (e.g. - platform_roll, platform_roll_clockwise,
> >platform_roll_anticlockwise - or similar names)
> >  *   Having three different versions of each standard name will
> >lead to new possibilities for getting things wrong by picking the
> >wrong version.
> >  *   Semantically, there is only one concept in each case. If I
> >am searching for roll variables and I have multiple names that
> >mean roll, I must expand my search to include all variants. This
> >is a small example, but there are other examples of this problem
> >that are definitely not trivial and defeat one of the goals for
> >using standard names - being able to find like quantities across
> >datasets, particula

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Jim

Thanks for your email.

>  * There is no single sign convention being followed in existing
>datasets "in the wild".

I am not surprised. That's similar with other quantities. I agree that we have
to be able to describe the quantities people wish to use. CF doesn't try to
dictate what quantities people should use. That is why we have standard names
of surface_downward_sensible_heat_flux and surface_upward_sensible_heat_flux,
to mention just one of many examples, since both are in use.

>  * There is a long-standing convention for vertical coordinates using
>the attribute positive rather than having pairs of standard names
>for height_positive_up, height_positive_down, etc. The suggested
>solution is corollary, and the positive attribute could be used
>instead of adding a new attribute named direction with a suitable
>expansion of possible valid values.

That is not a CF use of the positive attribute. In CF, the positive attribute
is for vertical coordinate variables, mainly for the convenience of programs
which want to know which way up to plot them, without needing to work it out
from any other information that might be given. In addition, any variable with
the positive attribute is interpreted as a vertical coordinate variable. This
is a convention which CF took over from the older COARDS netCDF convention.

All standard names indicate their sign convention in the name itself, and the
positive attribute is not a CF attribute of data variables.

>  * In order to cover all bases, we'd need three versions for each
>standard name (e.g. - platform_roll, platform_roll_clockwise,
>platform_roll_anticlockwise - or similar names)
>  * Having three different versions of each standard name will lead to
>new possibilities for getting things wrong by picking the wrong version.

I don't think there ought to be a standard name for the version without the
sign convention i.e. platform_roll in your example. That would be like having
a standard name for sensible_heat_flux without the sign convention. Unless
the unsigned quantity is something distinct, there are only two in each case.

Picking the wrong version can be done either way. If you have one standard
name for both conventions you might pick the wrong value of the sign-convention
attribute.  That's the same sort of mistake as using the wrong standard name. 
But if you have a separate attribute, further kinds of mistake can arise, of
omitting it altogether, or giving it an invalid value for your standard name.

>  * Semantically, there is only one concept in each case. If I am
>searching for roll variables and I have multiple names that mean
>roll, I must expand my search to include all variants. This is a
>small example, but there are other examples of this problem that are
>definitely not trivial and defeat one of the goals for using
>standard names - being able to find like quantities across datasets,
>particularly using automated techniques rather than human eyes.

This is no different from any of the many other cases where there are semantic
elements in common in groups of standard names. You may remember I gave a talk
at the meeting in Reading about why standard names group lots of different
semantic elements into one string. The sign convention is one of these. I think
these new platform standard names ought to be handled in the same way as we
have done for all other signed quantities in the standard name table.

Best wishes

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

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear all

I haven't been following this discussion, so please excuse me if I've missed
the point. I think you are suggesting introducing a new attribute to indicate
the positive sense of various new quantities for platform orientation - is
that right? To do that would not be consistent with other standard names, which
(where relevant) all have the positive sense indicate in the standard name
itself. That's why there are many pairs of standard names for upward/downward,
in particular. The reason for doing this is to make it impossible to name the
quantity without indicating its sign convention, whereas a separate attribute
can be omitted, and probably sometimes will. It also opens new possibilities
for getting things wrong, by putting illegal values in it.

Therefore I would argue for the same approach here, both because I think it's
less error-prone, and for consistency with other CF standard names. I'm sure
the objection occurs to you that this means more standard names. That's true,
but it's only twice as many, I believe, since each of the quantities has only
two possible senses.

Best wishes

Jonathan

- Forwarded message from Kenneth Kehoe  -

> Date: Thu, 30 Aug 2018 12:05:44 -0600
> From: Kenneth Kehoe 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
>   Gecko/20100101 Thunderbird/60.0
> 
> I think we should keep things simple as Ethan suggests below. But
> since the proposed attribute "direction" is defined as indicating
> the positive direction we don't need to include the word positive.
> 
> The terms would then be:
> roll: "right_side_up" and "right_side_down"
> pitch: "nose_up" and "nose_down"
> yaw: "nose_right" and "nose_left"
> surge: "forward" and "backward"
> sway: "left" and "right"
> heave: "up" and "down"
> 
> It would be nice to be more explicit in the netCDF file and require
> less on the standard_name definition so I would suggest we use the
> original proposed attribute name of "positive_direction" with the
> above allowed values.
> 
> Or if we don't want to add a new attribute we could use the existing
> "positive" attribute and expand its allowed use. I've proposed this
> in the past and it was decided to not expand the definition. I think
> the concern for not expanding positive was the requirement of only
> using that attribute on coordinate variables. For the coordinate
> variable the only allowable values are up and down. But for this use
> those values would only be attached to a variable, not a coordinate
> variable.
> 
> Since we are creating an attribute to define the positive direction
> I would like to add radial definition of "toward" and "away". But I
> think we can simplify this a bit further. If we define the point of
> reference that is moving in the standard name then we don't need to
> put the point of reference in the positive (or direction or
> positive_direction) attribute. For example the pitch standard_name
> would indicate the location of reference of the nose. This would
> then reduce the list of possible options to:
> 
> roll: "up" and "down"
> pitch: "up" and "down"
> yaw: "right" and "left"
> surge: "forward" and "backward"
> sway: "left" and "right"
> heave: "up" and "down"
> 
> If we could use the current attribute of "positive" that has up and
> down already defined then we only need to to add "right", "left",
> "forward", "backward", "toward", "away".
> 
> Easy!
> 
> 
> Ken
> 
> 
> 
> On 2018-8-29 13:54, Ethan Davis wrote:
> >Hey Jim,
> >
> >How about removing one layer of terminology by using your
> >definitions for the allowed values of "direction":
> >
> >roll: "positive_right_side_up" and "positive_right_side_down".
> >pitch: "positive_nose_up" and "positive_nose_down".
> >yaw: "positive_nose_right" and "positive_nose_left".
> >surge: "positive_forward" and "positive_backward".
> >sway: "positive_left" and "positive_right".
> >heave: "positive_up" and "positive_down".
> >
> >Cheers,
> >
> >Ethan
> >
> >On Wed, Aug 29, 2018 at 12:02 PM Jim Biard  >> wrote:
> >
> >John,
> >
> >There are a variety of conventions for defining roll, pitch, and
> >yaw out there. This is why we are avoiding a specific one. Others
> >have searched existing datasets that are using earlier versions of
> >these standard names (or not using standard names) and found that
> >they don't all follow the same convention.
> >
> >Ethan,
> >
> >We purposely aren't answering that question directly because of
> >the issue above. I believe that I have consistently followed the
> >convention in which clockwise and anticlockwise are rotational
> >directions around a unit vector facing the observer, where the X
> >unit vector is in the nominally forward direction, the Z axis is
> >in the local up direction, and the Y axis unit vector is "Z cross
> >X", which forms a right-handed coordinate system. The 

Re: [CF-metadata] [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Jonathan Gregory]

Dear David

I agree with your proposals to stop new trac tickets quite soon and to put the
conformance doc in the same git repository as the conventions doc.

Earlier and at the CF meeting last month I argued in favour of continuing with
trac for the moment, because I think it's important that potential contributors
to the conventions are not deterred from contributing. There are some to whom
the use of GitHub may seem a formidable barrier. (We know that there are others
who find that surprising, because they are familiar with GitHub and regard trac
as impenetrable. This legitimate difference of views reflects people's ways of
thinking and experience, I expect.) To help people start using GitHub, we will
have the guidelines, whose development Dave has been leading.

This is now the time and opportunity for anyone in the CF community to say if
they are concerned about the prospect of being required to use GitHub in the
near future to make proposals for changes to the conventions. (The use of the
email list for discussion and standard name proposals will continue.)

Best wishes

Jonathan

On Fri, Jul 13, 2018 at 12:50:21AM -0700, David Hassell wrote:
> Date: Fri, 13 Jul 2018 00:50:21 -0700
> From: David Hassell 
> To: cf-convention/cf-conventions 
> Cc: Subscribed 
> Subject: Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines
>  (#130)
> 
> Where I think we are on the outstanding questions:
> 
>   * **whether or not to run Trac in parallel for a while**
> 
> I suggest that, for new proposals, we do not run Trac and gihub for new 
> proposal parallel. In practice this would mean:
> 
> 1) We would set a date (that would presumably coincide with the 
> acceptance of this ticket) after which new proposals must be made on github 
> and no new proposals will be allowed on Trac. Discussions can continue on 
> Trac until ...
> 2) We set another, later date, after which Trac will be turned off and 
> its content archived. Any unfinished Trac discussions will be effectively 
> closed. If there is still a will to continue a discussion then the proposal 
> must be raised anew as a github issue proposal. (This is not as extreme as it 
> first sounded to me - there are Trac tickets that have been open but haven't 
> been posted to for over 10 years - these were never going to be resolved 
> before Trac is turned off!)
> 
>   * **whether or not to create new github issues in the cf-conventions repo, 
> the same repo as the copied Trac tickets, or yet another repo. [Whatever the 
> answer, labels will be in use to help discern issues.]**
> 
> It seems that there is support for copying the existing Trac tickets to a 
> new "archive" repository; but raising new proposals in the existing 
> cf-conventions repository. New proposals can happily coexist with other 
> issues (such as "should we use italics for example captions?") with the use 
> of labels.
> 
> We would "fast-forward" the issue numbers in the cf-conventions repo so 
> that new proposals would have different numbers to old ones - currently that 
> means creating dummy issues up to and including nunber 174. This is important 
> because if we didn't do this then our issue referencing could break in the 
> future if we were to alter our change procedure yet again (such as if github 
> were to ever fail to meet our needs). 
> 
>   * **whether or not to move the conformance document to the cf-conventions 
> repo**
> 
> There is a compelling reason for moving the conformance document to the 
> cf-conventions repository in that then there would only ever need to be one 
> pull request per completed proposal. In the current situation (i.e. 
> conformance in its own repo), some proposals will need two pull requests.
> 
> Thanks, David
> 
> -- 
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub:
> https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-404755429
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Standard Names to support Trac ticket 99

[Jonathan Gregory]

Dear Roy

Ah, OK. Thanks. Having thought about that, I went to look at ticket 99, and
found that I'd said the same thing five years ago in comment 1. As you see,
I'm bit-reproducible.

I propose that we should tidy the CF document by promoting 6.1.1 on "Geographic
regions" to 6.3 (i.e. remove it from 6.1), and adding yours as 6.4. Then 6.1
and 6.2 will describe mechanisms in CF, and 6.3 and 6.4 applications of these
mechanisms.

Does that seem OK?

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Thu, 12 Jul 2018 16:04:07 +
> From: "Lowry, Roy K." 
> To: "cf-metadata@cgd.ucar.edu" ,
>   "j.m.greg...@reading.ac.uk" 
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
> 
> Dear Jonathan,
> 
> 
> The extra text that I am preparing in the Trac ticket for addition to the CF 
> Conventions. I was hoping your familiarity with these could recommend a 
> suitable section for amendment.
> 
> 
> 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 Jonathan 
> Gregory 
> Sent: 12 July 2018 16:36
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
> 
> Dear Roy
> 
> That's good news. Thanks for your patience. I like this new proposal, but I'm
> not sure what you're asking me. Which extra text?
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from "Lowry, Roy K."  -
> 
> > Date: Thu, 12 Jul 2018 11:54:57 +
> > From: "Lowry, Roy K." 
> > To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
> >
> > Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
> >
> > Dear Jonathan,
> >
> >
> > Getting back to this now I've had some feedback. 'organisms_in_taxon' is 
> > fine and a remodelled proposal on this basis is given below. I'll try and 
> > get to your comments on the trac proposal in the coming week. To save me a 
> > lot of reading would you have a recommendation on where I should look to 
> > add the extra text?
> >
> >
> > Cheers, Roy.
> >
> > biological_taxon_name
> > biological_taxon_lsid
> > number_concentration_of_organisms_in_taxon_in_sea_water
> > mass_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> > mass_concentration_of_organisms_in_taxon_expressed_as_chlorophyll_in_sea_water
> > mass_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
> > mole_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> > mole_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
> >
> >
> > biological_taxon_name
> >
> > A plaintext human-readable label, usually a Latin binomial such as Calanus 
> > finmarchicus, applied to a biological taxon. Biological taxon is a name or 
> > other label identifying an organism or a group of organisms as belonging to 
> > a unit of classification in a hierarchical taxonomy.
> >
> > dimensionless
> >
> > biological_taxon_lsid
> >
> > The Life Science Identifier (LSID) is a standard URI for a biological 
> > taxon. Biological taxon is a name or other label identifying an organism or 
> > a group of organisms as belonging to a unit of classification in a 
> > hierarchical taxonomy. The LSID is a URN with the syntax 
> > ‘urn:lsid:::[:]’. For example, the 
> > copepod Calocalanus pavo may be represented by LSIDs 
> > ‘urn:lsid:marinespecies.org:taxname:104669’ (based on WoRMS) and 
> > urn:lsid:itis.gov:itis_tsn:85335’ (based on ITIS). These URNs may be 
> > converted to URLs delivering RDF by prefixing with 'http://lsid.tdwg.org/'.
> >
> > dimensionless
> >
> > number_concentration_of_organisms_in_taxon_in_sea_water
> >
> > Number concentration means the count of an entity per unit volume and is 
> > used in the construction ‘number_concentration_of_X_in_Y’, where X is a 
> > material constituent of Y.. Biological taxon is a name or other label 
> > identifying an organism or a group of organisms as belonging to a unit of 
> > classification in a hierarchical taxonomy. Number concentration of biota is 
> > also referred to as abundance.
> >
> > m-3
> >
> > mass_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> >
> > Mass concentration means mass per unit volume and is used in the 
> > construction ‘mass_concentration_of_X_in_Y’, whe

Re: [CF-metadata] Standard Names to support Trac ticket 99

[Jonathan Gregory]

Dear Roy

That's good news. Thanks for your patience. I like this new proposal, but I'm
not sure what you're asking me. Which extra text?

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Thu, 12 Jul 2018 11:54:57 +
> From: "Lowry, Roy K." 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
> 
> Dear Jonathan,
> 
> 
> Getting back to this now I've had some feedback. 'organisms_in_taxon' is fine 
> and a remodelled proposal on this basis is given below. I'll try and get to 
> your comments on the trac proposal in the coming week. To save me a lot of 
> reading would you have a recommendation on where I should look to add the 
> extra text?
> 
> 
> Cheers, Roy.
> 
> biological_taxon_name
> biological_taxon_lsid
> number_concentration_of_organisms_in_taxon_in_sea_water
> mass_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> mass_concentration_of_organisms_in_taxon_expressed_as_chlorophyll_in_sea_water
> mass_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
> mole_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> mole_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
> 
> 
> biological_taxon_name
> 
> A plaintext human-readable label, usually a Latin binomial such as Calanus 
> finmarchicus, applied to a biological taxon. Biological taxon is a name or 
> other label identifying an organism or a group of organisms as belonging to a 
> unit of classification in a hierarchical taxonomy.
> 
> dimensionless
> 
> biological_taxon_lsid
> 
> The Life Science Identifier (LSID) is a standard URI for a biological taxon. 
> Biological taxon is a name or other label identifying an organism or a group 
> of organisms as belonging to a unit of classification in a hierarchical 
> taxonomy. The LSID is a URN with the syntax 
> ‘urn:lsid:::[:]’. For example, the 
> copepod Calocalanus pavo may be represented by LSIDs 
> ‘urn:lsid:marinespecies.org:taxname:104669’ (based on WoRMS) and 
> urn:lsid:itis.gov:itis_tsn:85335’ (based on ITIS). These URNs may be 
> converted to URLs delivering RDF by prefixing with 'http://lsid.tdwg.org/'.
> 
> dimensionless
> 
> number_concentration_of_organisms_in_taxon_in_sea_water
> 
> Number concentration means the count of an entity per unit volume and is used 
> in the construction ‘number_concentration_of_X_in_Y’, where X is a material 
> constituent of Y.. Biological taxon is a name or other label identifying an 
> organism or a group of organisms as belonging to a unit of classification in 
> a hierarchical taxonomy. Number concentration of biota is also referred to as 
> abundance.
> 
> m-3
> 
> mass_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> 
> Mass concentration means mass per unit volume and is used in the construction 
> ‘mass_concentration_of_X_in_Y’, where X is a material constituent of Y. A 
> chemical species denoted by X may be described by a single term such as 
> 'nitrogen' or a phrase such as
> 'nox_expressed_as_nitrogen'. 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. Mass concentration of biota expressed as carbon is also 
> referred to as carbon biomass. Biological taxon is a name or other label 
> identifying an organism or a group of organisms as belonging to a unit of 
> classification in a hierarchical taxonomy.
> 
>  kg m-3
> 
> mass_concentration_of_organisms_in_taxon_expressed_as_chlorophyll_in_sea_water
> 
> Mass concentration means mass per unit volume and is used in the construction 
> ‘mass_concentration_of_X_in_Y’, where X is a material constituent of Y. A 
> chemical or biological species denoted by X may be described by a single term 
> such as 'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. 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. Chlorophyll means all naturally occurring pigments of the 
> chlorophyll group. Biological taxon is a name or other label identifying an 
> organism or a group of organisms as belonging to a unit of classification in 
> a hierarchical taxonomy.
> 
>  kg m-3
> 
>  mass_concentrati

Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into snowpack

[Jonathan Gregory]

iptive 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

- End forwarded message -
___
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

[Jonathan Gregory]

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 
> > 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
> Many thanks to Hyungjun Kim for clarifying these important questions.
> 
> I have used this explanation to finish writing definitions for these names. I 
> think most of the terms could now be accepted if you are happy with the 
> definitions. I have a question as to whether proposals 1.5 and 1.8 should 
> really include floating ice shelves, which seem to be explicitly excluded in 
> Hyungjun's text.
> 
> > 1.2 CMIP6 short name dgw. Change in Groundwater 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 (kg m-2)
> 
> From Hyungjun's description I have defined groundwater as 'Groundwater is 
> subsurface water below the depth of the water table.' This then gives us the 
> following definition for the proposed term:
> '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. 
> "Water" means water in all phases. Groundwater is subsurface water below the 
> depth of the water table. "Amount" means mass per unit area.'
> 
> Okay?
> 
> > 1.3 CMIP6 short name drivw. Change in River Storage 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 (kg m-2) "River 
> > + water amount refers to the water in the fluvial system (stream and 
> > floodplain)".
> 
> For the river flow names, we decided that they include water in all phases 
> (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020241.html, proposal 
> 5), therefore I assume this one does too. Hence the definition would be:
> '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. 
> "Water" means water in all phases. "River" refers to the water in the fluvial 
> system (stream and floodplain). "Amount" means mass per unit area.'
> 
> Okay?
> 
> > 1.5 CMIP6 short name dsn. Change in snow water equivalent (including 
> > snow and ice)
> > 
> > The ice includes all the ice above ground, including glaciers, ice sheets 
> > and floating ice shelves.
> > 
> > + Propose: change_over_time_in_surface_snow_and_ice_amount (kg m-2)
> 
> The 'ice_and_snow_on_land' definition we agreed in 
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020250.html for the 
> nudging standard name and area_type seems a better fit to the proposed 
> quantity than land_ice because it includes river and lake ice, as well as 
> snow.
> Hence I am changing my suggestion for this name to be:
> change_over_time_in_amount_of_ice_and_snow_on_land (kg 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. 
> "Amount" means mass per unit area. The phrase "ice_and_snow_on_land" 

[CF-metadata] Final 17 terms for CMIP6 LS3MIP: Heat flux into snowpack

[Jonathan Gregory]

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

Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6

[Jonathan Gregory]

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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] tendency_of_sea_water_conservative_temperature_expressed_as_heat_content units

[Jonathan Gregory]

Dear Martin

I agree with your suggestions and clarifications. It would be good to keep
"heat content" because it is widely understood (in the sense that we use it,
J m-2). I agree that "content" implies the amount of something per unit area
integrated over the vertical extent of something else. It's not used only for
mass content; we have a lot of energy content names too e.g.
  thermal_energy_content_of_surface_snow
and this last one suggests that maybe we could say "thermal energy" instead
of "sensible heat" in the name about rainfall temperature? (Sorry - that is
a hideous confusing of email threads by me.) In addition, we have enthalpy,
mole, number and radioactivity content names, all with the same sense.

Best wishes

Jonathan

- Forwarded message from Martin Juckes - UKRI STFC 
 -

> Date: Mon, 25 Jun 2018 13:06:26 +
> From: Martin Juckes - UKRI STFC 
> To: "cf-metadata@cgd.ucar.edu" ,
>   "j.m.greg...@reading.ac.uk" 
> Subject: Re: [CF-metadata]
>   tendency_of_sea_water_conservative_temperature_expressed_as_heat_content
>   units
> 
> 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 si

Re: [CF-metadata] Precipitation fractions for LS3MIP

[Jonathan Gregory]

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_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.'
> 
> fraction_of_solid_precipitation_mass_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 
> fraction_of_solid_precipitation_mass_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.'
> 
> Are these okay? If so I think they can be accepted.
> 
> 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 Alison 
> Pamment - UKRI STFC
> Sent: 11 June 2018 11:33
> To: 'Karl Taylor' ; Juckes, Martin (STFC,RAL,RALSP) 
> ; CF-metadata (cf-metadata@cgd.ucar.edu) 
> 
> Subject: Re: [CF-metadata] Precipitation fractions for LS3MIP
> 
> Dear Martin, Karl and Steve,
> 
> Thank you for the proposing these two names and the comments received so far.
> 
> fraction_of_rainfall_mass_falling_onto_surface_snow (1) 'The phrase 
> "surface_snow" means snow lying on the surface.'
> 
> fraction_of_solid_precipitation_mass_falling_onto_surface_snow (1) 'The 
> phrase "surface_snow" means snow lying on the surface. 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 names and units look fine.
> 
> Are these variables calculated over quite large areas? If so, would it be 
> appropriate to add the following sentence to their definitions:
> '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'?
> 
> This is what we do with names like land_ice_mass where the quantity might 
> represent the mass of a whole ice sheet, rather than something calculated in 
> a small lat-long grid box.
> 
> 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: CF-metadata  On Behalf Of Karl Taylor
> Sent: 05 June 2018 17:03
> To: Steven Emmerson ; Juckes, Martin (STFC,RAL,RALSP) 
> 
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Precipitation fractions for LS3MIP
> 
> Hi all,
> 
> I think in common usage "mass fraction" is 

Re: [CF-metadata] Final 17 terms for CMIP6 LS3MIP.

[Jonathan Gregory]

Dear Alison and Martin

> 3.1 hfrs Heat transferred to snowpack by rainfall [W m-2]
> 
> Martin has suggested the following:
> 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 certainly prefer this term to having a temperature flux! We define 
> 'anomaly' in existing names as follows: 'The term "anomaly" means difference 
> from climatology' so I think it would be misleading to use the same term 
> here. We have one existing name that refers to a temperature 'excess' - 
> integral_wrt_time_of_air_temperature_excess where excess is calculated 
> relative to a threshold specified in a coordinate variable. Perhaps we could 
> call this quantity:
> surface_downward_sensible_heat_flux_due_to_rainfall_temperature_excess_above_freezing

I like excess_above_freezing (if that's what is needed). I'm still not
comfortable with calling this "sensible heat", owing to that term *usually*
meaning turbulent fluxes in air. Maybe "sensible" could just be omitted? In
view of the due_to this couldn't be misinterpreted as a latent or radiative
heat flux, I'd say.

> 5. Regarding the river transport names, I did in fact publish them in Version 
> 55 of the standard name table as river_water_volume_transport_into_cell and 
> river_water_volume_transport_out_of_cell, so if we now decide on one of the 
> other options we will need to create aliases. I don't have very strong 
> feelings about any of the variations that have been put forward, but if we 
> are to avoid the mention of cells then perhaps we could have:
> inward_water_volume_transport_within_river_channel
> outward_water_volume_transport_within_river_channel
> i.e. saying 'within' channel so that people won't mistake it for flow into or 
> out of the channel itself. This is also very general because it avoids 
> assumptions about what is upstream or downstream.

OK. Rather than "within" you could say "along", perhaps, or more explicitly
it could be "incoming transport from river channel" and "outgoing transport
to river channel". We use incoming/outgoing for TOA radiation.

Best wishes

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

Re: [CF-metadata] SIMIP: 5 standard names and one area type for CMIP6

[Jonathan Gregory]

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

Re: [CF-metadata] tendency_of_sea_water_conservative_temperature_expressed_as_heat_content units

[Jonathan Gregory]

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 an important one and it 
> would be better to be clear in the names that the quantities are vertical 
> integrals if that is indeed the case. The bounds can then be used to describe 
> the limits, as above. I think it would then be okay to describe something as 
> being the tendency of an integrated quantity.  My own question related to the 
> order in which the operations are carried out on the variable, I.e. is it the 
> tendency of the vertical integral, or the vertical integral of the tendency?
> 
> Best wishes,
> Alison
> 
> From: Stephen Griffies - NOAA Federal 
> Sent: 21 June 2018 14:00:46
> To: Pamment, Alison (STFC,RAL,RALSP)
> Cc: Juckes, Martin (STFC,RAL,RALSP); 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
> 
> Alison,
> 
> Thanks for staying on top of these matters.
> 
> The diagnostics "tendency_of_sea_water_" refer to the tendency as integrated 
> over the thickness of a single model grid cell.
> 
> In contrast, 
> "integral_wrt_depth_of_sea_ice_temperature_expressed_as_heat_content " is an 
> integral over the full ocean depth from bottom to top.
> 
> I recommend we keep the naming convention unchanged in order to clearly 
> distinguish between the two diagnostics.
> 
> Stephen
> 
> 
> 
> 
> 
> On Thu, Jun 21, 2018 at 2:42 AM, Alison Pamment - UKRI STFC 
> mailto:alison.pamm...@stfc.ac.uk>> wrote:
> Dear Martin, Stephen and Jonathan,
> 
> We have seven existing 
> tendency_of_sea_water_conservative_temperature_expressed_as_heat_content 
> names (and seven existing 
> tendency_of_sea_water_potential_temperature_expressed_as_heat_content 
> names)all with units of W m-2. I think all of these were introduced for OMIP.
> 
> If something is described as a 'heat content' I would expect it to have units 
> of J m-2. Indeed that is the case for the two existing names
> integral_wrt_depth_of_sea_ice_temperature_expressed_as_heat_content and 
> integral_wrt_depth_of_sea_water_potential_temperature_expressed_as_heat_content.
>  Calculating tendencies of such quantities would then give us units of W m-2. 
> This suggests to me that the OMIP names should all follow the pattern:
> tendency_of_integral_wrt_depth_of_sea_water_X_temperature_expressed_as_heat_content
> where X is 'potential' or 'conservative'. The bounds of the vertical 
> coordinate variab

Re: [CF-metadata] additional standard name for ISMIP6

[Jonathan Gregory]

Dear Sophie, Alison and all

A comment on just one of these.

> > 2. land_ice_basal_temperature (K)
> Answer from Sophie:
...
> Yes, Alison’s revised definition is great. I am wondering if to be more 
> consistent with “temperature_at_top_of_ice_sheet_model”, whether the long 
> name should become “temperature_at_base_of_ice_sheet_model”. I don’t mind 
> either way.

I think that the base of the ice sheet is a physical concept, apart from
models - it's an interface between ice and rock. So I'd say that the different
phraseology is fine, and it's better to avoid model names when we can.

Best wishes

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