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.
Received on Fri Mar 31 2017 - 10:04:06 BST
