Superb outcome. Cheers, Roy.
Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquiries at bodc.ac.uk. Please also use this e-mail if your requirement is urgent.
________________________________
From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Durack, Paul J. <durack1 at llnl.gov>
Sent: 13 April 2017 18:35
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for OMIP biogeochemistry and chemistry
Ok great this simplifies things considerably. So, we can drop the request for these separate ?surface_? names, which cleans up the 51 names that Alison was questioning. I believe in the OMIP data request these variables are uniquely names (e.g. dissic vs dissicos [surface is last]), so only the standard_names require updating in the google sheet.
Alison, what other open questions remain unanswered from your comprehensive email dated 29th March 2017? I believe we are close to the finish line on this large standard name request.
Cheers,
P
On 4/11/17, 4:00 AM, "CF-metadata on behalf of James Orr" <cf-metadata-bounces at cgd.ucar.edu on behalf of James.Orr at lsce.ipsl.fr> wrote:
Paul,
> So, use a single standard_name (for the identical quantity), and keep
> the second 2D (CMOR) variable (as is the status of the current CMIP6
> data request). I believe this solution would solve many of the 51
> ?surface? variables that Alison highlighted, as these requests could
> be dropped in favor of their 3D (existing) names.
Your suggestion is excellent. Using the same standard-name but a
different "CMIP name" to indicate the surface variable would be a
fine solution.
> As an aside, the ?depth0m? current CMOR_dimension is not correct
> either. I assume these variables will be reported for the top ocean
> level, which in CMIP5 was 0-10m reported as 5m for many models, and
> for CMIP6 will be varied across the model suite. Jim/John, should this
> be clarified? Martin, would you care to comment here?
Yes, for these "sea surface" variables, we mean the top layer of the
ocean model. In CMIP6, the thickness of that layer will indeed vary
among ocean models. Any ideas for clarification are welcome although
most ocean modelers should not need it.
Best,
Jim
On Thu, 6 Apr 2017, Durack, Paul J. wrote:
> To answer the ?surface? question raised by Alison, and posed by Jim (the bottom of this email) - apologies for the tardy response.
>
> The analogue in the physical domain are the tos and sos variables which are the ?surface? (or more correctly top model level) 2D equivalents of their counterpart 3D variables thetao and so.
>
> In this instance, we could have two variables with the same standard_name and differing ?CMIP name?, so for example:
>
> The originally proposed variables and standard_names (see biogeochemistry sheet: https://goo.gl/Fyr6QW)
>
> dissicos ? CF_standard_name: surface_mole_concentration_of_dissolved_inorganic_carbon_in_sea_water; CMOR_dimensions: longitude latitude time depth0m (Omon line 7)
> dissic ? CF_standard_name: mole_concentration_of_dissolved_inorganic_carbon_in_sea_water; CMOR_dimensions: longitude latitude olevel time (Omon line 60)
>
> Could be finalized as:
>
> dissicos ? CF_standard_name: mole_concentration_of_dissolved_inorganic_carbon_in_sea_water; CMOR_dimensions: longitude latitude time depth0m
> dissic ? CF_standard_name: mole_concentration_of_dissolved_inorganic_carbon_in_sea_water; CMOR_dimensions: longitude latitude olevel time
>
> So, use a single standard_name (for the identical quantity), and keep the second 2D (CMOR) variable (as is the status of the current CMIP6 data request). I believe this solution would solve many of the 51 ?surface? variables that Alison highlighted, as these requests could be dropped in favor of their 3D (existing) names.
>
>
> As an aside, the ?depth0m? current CMOR_dimension is not correct either. I assume these variables will be reported for the top ocean level, which in CMIP5 was 0-10m reported as 5m for many models, and for CMIP6 will be varied across the model suite. Jim/John, should this be clarified? Martin, would you care to comment here?
>
>
> Cheers,
>
> P
>
> On 4/6/17, 10:51 AM, "CF-metadata on behalf of martin.juckes at stfc.ac.uk" <cf-metadata-bounces at cgd.ucar.edu on behalf of martin.juckes at stfc.ac.uk> wrote:
>
> Hello All,
>
> I'd like to support Alison on point 4 (see http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059357.html ), regarding the proposal for new standard names for near surface tracer fields.
>
> The statement 'The surface called "surface" means the lower boundary of the atmosphere' occurs in many standard name definitions: introducing a new set of names in which "surface" means "near surface" introduces an unnecessary ambiguity.
>
> I also note that some of these variables have already been requested in CMIP5, using the approach described by Karl.
>
> regards,
> Martin
>
> On 3/31/17, 9:04 AM, "CF-metadata on behalf of Jonathan Gregory" <cf-metadata-bounces at cgd.ucar.edu on behalf of j.m.gregory at reading.ac.uk> wrote:
>
> Dear Alison
>
> I second Jim Orr's vote of thanks to you for your great efforts on these names
> and several other sets recently.
>
> I accept your recommendation not to introduce new names for surface con-
> centrations if these aren't really *at* the surface. I agree that it's
> consistent with other cases, such as near-surface air temperature, to use
> a coordinate instead. My reply to Karl was about the case when the quantity
> is truly *at* the surface, in which case there are many equivalent choices
> of coord, and that's not convenient. It's more informative too to include a
> coordinate value.
>
> I don't think will be a problem for analysts in finding the data because, as
> Karl said, the 2D and 3D versions would have different CMIP6 quantity names
> (the ones like tas and thetao) and reside in different files for CMIP6.
>
> Best wishes
>
> Jonathan
>
> > >4. When is a surface not a surface?
> > >
> > >There are 3 proposed names for surface fluxes. Such names clearly
> > >refer to conditions at the air/sea interface and it is correct to
> > >label them as surface quantities. Those names are excluded from
> > >the discussion in this section.
> > >
> > >There are 51 proposed names referring to
> > >'surface_mole_concentration', 'surface_mass_concentration',
> > >'surface_sea_water_ph' and 'surface_sea_water_alkalinity'. These
> > >are the names I want to discuss here. We have already had some
> > >discussion of these names on the mailing list and there has been
> > >some further on and off-list discussion over the last couple of
> > >days. So far we have not arrived at consensus, but it is important
> > >that we try to do so now to allow the majority of the remaining
> > >OMIP names to be accepted. I will attempt to summarize the
> > >discussion and then make a recommendation as to how I think we
> > >should proceed.
> > >
> > >The reason for the discussion is that the surface concentration
> > >and alkalinity names have all been proposed with units of mol m-3
> > >or kg m-3, which indicates that the named quantities are intended
> > >to represent 'near surface' layer concentrations, i.e., the top
> > >one or two levels in an ocean model. Although the ph names are
> > >dimensionless it is clear that these also are intended to
> > >represent a near surface layer. In CF standard names it is
> > >inappropriate to refer to these layer quantities simply as
> > >'surface' quantities because the term 'surface' is defined as 'the
> > >lower boundary of the atmosphere', i.e. it is the exact interface
> > >between air and sea which therefore has no thickness or volume and
> > >is therefore unsuitable for use with units of m-3.
> > >
> > >At an earlier point in the discussion
> > >(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/059044.html)
> > >I mentioned that we have a small number of existing sea_surface
> > >names - these are near surface layer quantities and nearly all
> > >relate to specific definitions of sea surface temperature, e.g.,
> > >sea_surface_skin_temperature is defined as 'the temperature within
> > >the conductive diffusion-dominated sub-layer at a depth of
> > >approximately 10 - 20 micrometers below the air-sea interface'.
> > >The only generic quantity is sea_surface_temperature which is a
> > >deliberately vague term to cover different definitions of SST that
> > >have been used historically, for example, when making temperature
> > >measurements using the water in a ship's engine intake or by
> > >lowering a bucket over the side. These are all in some sense 'near
> > >surface' values but the depth of measurement can vary widely and
> > >in some cases may not even be recorded. I did toy with the idea
> > >that for OMIP we could have 'sea_surface' names for near-surface
> > >quantities because this would at least be consistent with the m-3
> > >in the units. However, I don't think this is the most satisfactory
> > >approach because the OMIP quantities can perfectly well be
> > >described by using standard names that can apply to quantities at
> > >any depth in conjunction with coordinate variables and coordinate
> > >bounds to state the actual depth and thickness of the surface
> > >layer. Even if we did introduce sea_surface names for OMIP it
> > >would still be necessary to supply the coordinate information in
> > >other metadata attributes to fully describe the location of the
> > >data, so it wouldn't do anything to reduce the amount of metadata
> > >that would need to be provided. Not to supply this metadata would
> > >render the data far less useful. Furthermore, other contributors
> > >to the discussion (Roy, Jonathan) have clearly expressed the view
> > >that we should not generalise the rather specialised
> > >sea_surface_temperature approach to other variables.
> > >
> > >In his most recent post, Jim has said that many fields will be
> > >output as 2D quantities in order to reduce the amount of data
> > >generated for OMIP. Karl has already explained that from a CMIP6
> > >viewpoint this is perfectly consistent with using standard names
> > >that could equally well apply to 3D quantities. It is also
> > >consistent with usual practice in CF. There is no limitation on
> > >the number of data variables in a CF-NetCDF file that can have the
> > >same standard name and they do not all have to have the same
> > >dimensions, so it's even possible to have 2D and 3D fields with
> > >the same standard name in the same file. The important point for
> > >data users is not to rely solely on the standard name to decide
> > >how to treat a variable, but also to examine many other metadata
> > >attributes such as coordinate variables, coordinate bounds and
> > >cell_methods. This is the always the correct way to work with CF
> > >metadata. Indeed, I would argue that the most 'standard' way to
> > >record the OMIP near-surface data in your files is to follow the
> > >practice I described earlier: use standard names that can apply to
> > >any depth and supply coordinate variables and coordinate bounds to
> > >state the actual depth and thickness of the surface layer. I think
> > >users of the data are more likely to discover data named in this
> > >way than if we introduce special sea_surface names for some
> > >quantities. Also, this approach significantly reduces the number
> > >of new standard names needed for OMIP. For example, the proposed
> > >name [sea_]surface_mole_concentration_of_carbonate_expressed_as_carbon_in_sea_water
> > >could be dropped in favour of using the existing name
> > >mole_concentration_of_carbonate_expressed_as_carbon_in_sea_water.
> > >Again, it is standard practice in the CF community to avoid adding
> > >new standard names that are not strictly necessary.
> > >
> > >Based on the above arguments I recommend that we follow the second approach
> > >and don't introduce separate sea_surface names. Please can those
> > >of you who have been engaged in this discussion indicate whether
> > >you are in agreement. If we can get consensus, or at least a clear
> > >majority on which approach to use, then many of the outstanding
> > >names can be accepted very quickly. If we are unable to reach a
> > >decision through this discussion, then I will need to call on the
> > >CF committee to vote on their preferred approach. The committee's
> > >decision will be final. This is in accordance with usual CF
> > >procedures.
> >
> > It would be great if we could come to an agreement on this issue by
> > ourselves, without having to bother the CF committee.
> >
> > If we adopt the idea to use the same name for variables whether they
> > are 3-D (full water column) or 2-D (sea surface only), that could
> > confuse typical users of the CMIP6 data. For CMIP5, users searched
> > for available data files based on variable names along with other
> > criteria in the CMIP5 Data Reference Syntax (DRS), which includes
> > keywords for Institute, Model, Experiment, Frequency, Realm, MIP
> > Table, Ensemble, Version, Variable, and Temporal Subset. No keyword
> > currently exists for spatial dimensions. So removing "sea surface"
> > from the variable names would not be optimal unless a new keyword
> > such as "Spatial Domain" could be added to the CMIP6 DRS.
> >
> > Paul, is this something that could be considered for CMIP6?
> > Otherwise, I would prefer to keep the "sea surface" prefix, as
> > previously adopted for the physical variables, 'sea surface
> > temperature' and 'sea surface salinity' (tos, sos).
> >
> > As for having 2 variables in the same file with the same name but
> > different shapes or dimensions, that would be confusing, both to
> > users and to software that is often used to analyze model output.
> > Would CMIP6 even allow such a practice. In any case, because the
> > Temporal frequency of the 2 variables would differ, that solution
> > does not seem practical.
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> On 3/29/17, 7:08 AM, "James Orr" <James.Orr at lsce.ipsl.fr> wrote:
>
> If we adopt the idea to use the same name for variables whether they are 3-D
> (full water column) or 2-D (sea surface only), that could confuse typical users
> of the CMIP6 data. For CMIP5, users searched for available data files based on
> variable names along with other criteria in the CMIP5 Data Reference Syntax
> (DRS), which includes keywords for Institute, Model, Experiment, Frequency,
> Realm, MIP Table, Ensemble, Version, Variable, and Temporal Subset. No keyword
> currently exists for spatial dimensions. So removing "sea surface" from the
> variable names would not be optimal unless a new keyword such as "Spatial
> Domain" could be added to the CMIP6 DRS.
>
> Paul, is this something that could be considered for CMIP6? Otherwise, I would
> prefer to keep the "sea surface" prefix, as previously adopted for the physical
> variables, 'sea surface temperature' and 'sea surface salinity' (tos, sos).
>
>
--
LSCE/IPSL, Laboratoire des Sciences du Climat et de l'Environnement
CEA-CNRS-UVSQ
LSCE/IPSL, CEA Saclay
http://www.ipsl.jussieu.fr/~jomce
Bat. 712 - Orme mailto: James.Orr at lsce.ipsl.fr
Point courrier 132
F-91191 Gif-sur-Yvette Cedex Phone: (33) (0)1 69 08 39 73
FRANCE Fax: (33) (0)1 69 08 30 73
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170413/c0a589c7/attachment.html>
Received on Thu Apr 13 2017 - 12:02:45 BST
