Alison,
Many thanks for your detailed and useful comments. I have commented
only on those names where you provided comments. In short, I have
absorbed nearly all of your suggestions. Perhaps the only unresolved
issue concerns how CF should standardize
1/ Fortran routines (should it do so?)
2/ grid specifications (before standard names, we need a standard suite
of grid fields sufficient to specify those grids used today for climate
modelling)
I believe these issues are nontrivial and will need to be discussed on a
separate email stream.
Best,
Stephen
Pamment, JA (Alison) wrote:
> Dear Stephen,
>
> Please see below for my responses to all the standard names you proposed
> in your document
> http://www.clivar.org/organization/wgomd/wgomd_publications.php. I
> think you will see that for the most part I am happy to accept the names
> as proposed, but I have made a few suggestions for slight modifications
> to some of the names. I am aware that you want to finalise the names
> for CMIP5 soon and I hope these responses will assist you in doing so.
>
> For the purpose of commenting on individual names I have labelled your
> proposals as X.Y where X is your table number and Y is the number of the
> entry in the table. Where a name in one of your tables is already in
> the CF standard name table I have (except in one or two cases) not
> included a comment.
>
> Table 1.
> 1.1 equation of state - This would need underscores instead of spaces,
> thus: equation_of_state.
>
Given your comment to 1.2, I suggest: sea_water_equation_of_state
> 1.2 seawater freezing temp - As in 1.1, underscores need to be added.
> 'seawater' is divided into two words in existing standard names, also
> 'temp' should be expanded to say 'temperature'. I think that the name
> sea_water_freezing_temperature sounds as though one might expect to find
> actual temperature values in the varaiable and I wonder if it might be
> better to call it sea_water_freezing_temperature_formula. What do
> others think?
>
More consistent with 1.1, I suggest:
sea_water_freezing_temperature_equation
> Presumably both of these quantities are described by formulae which will
> differ between models. Your table says that the actual formulae will
> consist of Fortran code. Is the idea that these 'data' will be placed
> in a character variable something like the following?
>
> dimensions:
> nlines = 1 ; // no. of lines of FORTRAN code supplied
> maxlen = 80 ; // max string length used to supply FORTRAN code
> variables:
> char swft(nlines,maxlen) ;
> swft:standard_name = "sea_water_freezing_temperature_formula" ;
> swft:canonical_units = "1" ;
> data:
> swft = "TF = -0.0575*S + 0.001710523*SQRT(S**3) - 0.0002154996*S**2 -
> 0.00753*p" ;
>
> If this is what you intend, then I think the canonical_units in the
> standard name table should be '1', i.e. dimensionless and the definition
> of the standard name would explain that the contents are strings. This
> is our usual practice for string valued variables.
>
My desire is to have the CMIP5 participants archive their equation of
state and seawater freezing equation. Do you think we need to make
these Fortran codes into a CF standard name? Perhaps we can just
consider this issues as part of the CMIP5 request outside of CF.
> 1.5 grid specification (lengths, areas) with units of m and m2.
> I assume here that you are thinking of names such as grid_length and
> grid_area? We already have a name cell_area with units of m2, defined
> as the horizontal area of a gridcell, which sounds like it is probably
> the quantity you need. Currently we don't have standard names for other
> grid metrics, but area and volume can be recorded in the cell_measures
> attribute (see Section 7.2 of the CF Conventions). Regarding
> grid_length, I think this is something that would usually be calculated
> from the cell boundaries given in a bounds variable. See also my
> comments on proposal 2.11 cell_thickness.
>
>
The discussion of a standard grid file is beyond this present document,
and beyond my expertise. I defer to others for finalizing a community
sanctioned grid specification file (with sufficient information to
specify an arbitrary curvilinear grid), and then to have standard names
for each of the grid fields. My understanding is that the present suite
of fields in CF are not sufficient for all the grids presently in use by
global climate models (e.g., tripolar, cubed sphere, icosahedral).
What we need for CMIP5 is this grid information, in total, including
information for arbitrary curvilinear grids. How that information is
archived needs to be resolved. There are folks in the community
cognizant of this issue, and hopefully they will reach a conclusion
soon, at which point they can iterate with CF for standardizing the names.
> 1.6 region.
> Although your table indicates that this quantity is new to CMIP5, we do
> already have a CF standard name of "region". It is a CF recommendation
> that, where possible, variables having this standard name take their
> values from the standardized list of region names at
> http://www.cfconventions.org/documents/cf-standard-names/standardized-re
> gion-names.
>
I believe the region names are taken from this list.
> Table 2
>
> 2.2 sea_water_pressure_at_sea_floor; Pa - The name is fine. I note that
> we already have the name sea_water_pressure in the standard name table
> and that this quantity has a canonical_unit of dbar. Clearly the units
> can be converted, but I think that we should aim for consistent
> canonical_units for these two names. Does it make more sense to use
> dbar or Pa?
>
As you note, dbar is indeed better, so I will change the recommended
units from Pa to dbar.
> 2.3 sea_water_pressure_at_sea_water_surface; Pa. I appreciate that this
> is a different quantity to surface_air_pressure and therefore we need a
> new name. However, do we need to say sea_water_surface or would it
> suffice to say surface_sea_water_pressure? ('Surface' is defined in
> standard names to mean the lower boundary of the atmosphere which
> therefore would also be the upper boundary of the ocean).
>
>
surface_sea_water_pressure sounds fine to me.
> 2.8 global_average_steric_sea_level_change; m. OK. We already have the
> names global_average_sea_level_change and
> global_average_thermosteric_sea_level_change and this new proposal is
> consistent. Am I correct in thinking that steric sea level change is
> the sum of thermosteric and halosteric contributions to changes in sea
> water density?
>
Correct, though halosteric is not so important, so generally it is
ignored.
> 2.10 cell_mass_per_area; kg m-2. Does this mean the mass per unit area
> of the sea water contained within each grid cell? If so, I suggest the
> name should be mass_of_sea_water_per_unit_area which would be similar to
> the existing name atmosphere_mass_of_air_per_unit_area.
>
>
I agree.
> 2.11 cell_thickness; m. See also my comments on proposal 1.5 "grid
> specification". Cell_thickness would usually be calculated from the
> bounds on the vertical coordinate variable. Names such as cell_length
> and cell_thickness have been discussed on the mailing list in the past
> and have received equivocal support. See, for example, the conversation
> we had in 2006 on cell_metrics in
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001068.html and
> following messages. I note that both Ian Culverwell and Jonathan seem
> to support the idea of introducing cell_thickness as a new quantity in
> the cell_measure attribute. I too think that would be a sensible
> approach rather than introducing it as a new standard name. This will
> require a proposal for a small modification to the CF conventions which
> needs to be opened as a new ticket on the CF trac system. I will submit
> a proposal to the trac system to take this forward as there is clearly a
> demand for somewhere convenient to access this type of grid metric
> information.
>
>
I caution against considering thickness in the same manner as horizontal
area. Thickness is generally a time dependent field that must be
computed using a prognostic equation, whereas horizontal area in most
models is static (except those few models with dynamical grids).
> 2.13 sea_surface_temperature; K. This quantity is already in the
> standard name table. For information, I would like to point out that we
> have recently introduced the following standard names for related
> quantities: sea_surface_skin_temperature,
> sea_surface_subskin_temperature, sea_surface_foundation_temperature. I
> am drawing attention to the existence of these names in case they are
> relevant to the CMIP5 work.
>
>
Thanks for the pointer. sea_surface_temperature is sufficient for CMIP5.
> 2.17 sea_water_age_since_surface_contact; year. The name sounds fine.
> I think the canonical_units in the standard name table should probably
> be seconds, rather than years because of the way UDunits defines a year.
> For more information on this please see Section 4.4 of the CF
> Conventions.
>
>
The nearly universal unit for age in oceanography is years. Can we make
an exception here?
> 2.18 moles_of_cfc11_per_unit_mass_in_sea_water; mol kg-1. I would
> slightly re-order this name to read
> moles_per_unit_mass_of_cfc11_in_sea_water so that its syntax is more
> consistent with existing mole_fraction and mole_concentration standard
> names. I think moles_per_unit_mass with units of mol kg-1 is fine.
> 'mole_fraction' implies units of mol mol-1 (i.e. dimensionless) and
> 'mole_concentration' means the units are mol m-3 so we clearly need a
> new description for your units.
>
>
Sounds good.
> 2.22 ocean_mixed_layer_thickness_defined_by_mixing_scheme; m. I would
> understand this to mean the depth of the mixed layer as calculated by a
> model's own mixing scheme - is that correct? I think the name is OK.
>
>
Correct.
> Table 3.
> 3.3 upward_ocean_mass_transport; kg s-1. OK. We already have a number
> of ocean salt and heat transport names in the table. I assume the mass
> referred to in this name is that of the sea water including salt.
> Correct?
>
Correct. I will clarify this point in the report.
> 3.7 ocean_meridional_overturning_mass_streamfunction; kg s-1. The name
> is OK. The description of the existing standard name
> ocean_meridional_overturning_streamfunction says "The ocean meridional
> overturning streamfunction should not include not include "bolus" or
> Gent-McWilliams velocity." Presumably the mass streamfunction is
> defined in an analogous way?
>
In fact, as detailed in the report, the field
ocean_meridional_overturning_mass_streamfunction should include ALL
physical processes, resolved or parameterized, that impact mass/volume
transport. This specification deviates from the
ocean_meridional_overturning_streamfunction specification. This
specification is in response to the physically relevant transport being
that arising from all processes.
> 3.8 ocean_y_overturning_mass_streamfunction; kg s-1. OK. Presumably
> this also excludes bolus and Gent-McWilliams contributions?
>
>
In fact, this includes bolus, and any other parameterized processes
impacting the overturning.
>
> Table 4.
> As I mentioned earlier, CF does have a defined set of standardized
> region names whose use is described in Section 6.1 of the conventions
> document. The region names are not, however, standard names in their
> own right and do not appear in the standard name table. Similarly, your
> region names would not need to become CF standard names. I note that
> you have defined the extent of your named areas and it may be possible
> to add them to the standardized list at a later date.
>
Sounds reasonable.
> Table 5.
> The majority of names in table 5 are already in the standard name table.
> Only two are new proposals.
>
>
OK.
> 6.3 virtual_salt_flux_into_sea_water_due_to_rivers; kg m-2 s-1. I
> suggest that we amend this name slightly to read
> virtual_salt_flux_into_sea_water_from_rivers because in standard names
> we reserve the phrase 'due to' to refer to a physical process as in the
> previous two names, for example. 'from_rivers' is also more consistent
> with the water flux names.
>
OK.
>
> 6.8 salt_flux_from_rivers_into_sea_water; kg m-2 s-1. I suggest that
> this name should be re-ordered to read
> salt_flux_into_sea_water_from_rivers for consistency with the water flux
> names.
>
OK
> Table 7
>
> 7.2 rainfall_temperature_flux_expressed_as_heat_flux; W m-2.
> 7.3 evaporation_temperature_flux_expressed_as_heat_flux; W m-2.
> 7.4 temperature_flux_into_sea_water_from_runoff_expressed_as_heat_flux;
> W m-2.
> I have thought hard about these three names because initially I wasn't
> very keen on the use of 'temperature flux' but having studied the
> definitions in section 4.5.3 of your document I can see what you mean
> and I can't think of an obvious improvement. To make the three names
> more consistent with one another and with existing names I would suggest
> a slight rewording as follows:
> 7.2
> temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water;
> W m-2;
> 7.3
> temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_wa
> ter; W m-2;
> 7.4
> temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water; W
> m-2.
> These are a bit longer than the original proposals but they all now
> follow the same pattern and it is clear in which direction the flux is
> positive.
>
OK. Thanks for the careful thought.
> 7.6 heat_flux_into_sea_water_due_to_icebergs; W m-2. Is this quantity
> analogous to 7.5, i.e. would it be better to say
> heat_flux_into_sea_water_due_to_iceberg_thermodynamics?
>
>
Agree with your altered name
heat_flux_into_sea_water_due_to_iceberg_thermodynamics
> Table 8.
> Please note that the canonical units for the quantities listed in table
> 8 would appear in the standard name table as Pascals, which is exactly
> equivalent to N m-2.
>
>
Indeed. I will make this note in the table caption.
> Table 9.
> 9.3 ocean_vertical_tracer_diffusivity_due_to_background; m2 s-1. OK.
> >From your document I understand 'due_to_background' to mean a static
> imposed field which may be either a constant value over the globe or
> spatially varying, depending on the model used. Is that the correct
> interpretation?
>
>
Yes, correct.
> 9.6 tendency_of_ocean_potential_energy_content_due_to_tides; W m-2. OK.
> I am aware that distinctions can be made between a number of different
> ocean tides and indeed we have recently introduced standard names for
> sea surface heights due to various tidal components. Please could you
> supply a sentence or two that can be included in the definitions of
> 'due_to_tides' names so that it is clear which processes are
> included/excluded.
>
Will do. In short, "due to tides" is a catch-all for "due to
astronomical gravity changes which manifests as tides". We do not
distinguish tidal components for these parameterizations.
>
> Best wishes,
> Alison
>
> ==> Please note new email address: alison.pamment at stfc.ac.uk <==
>
> ------
> J Alison Pamment Tel: +44 1235 778065
> NCAS/British Atmospheric Data Centre Fax: +44 1235 446314
> Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk
> Chilton, Didcot, OX11 0QX, U.K.
>
>
--
Stephen M. Griffies phone: +1-609-452-6672
Geophysical Fluid Dynamics Laboratory FAX: +1-609-987-5063
Princeton Forrestal Campus Rte. 1 email: stephen.griffies at noaa.gov
201 Forrestal Road http://www.gfdl.noaa.gov/~smg
Princeton, NJ 08542-0308 USA
Received on Fri Jan 09 2009 - 12:27:09 GMT
