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: [email protected] <==
------
J Alison Pamment Tel: +44 1235 778065
NCAS/British Atmospheric Data Centre Fax: +44 1235 446314
Rutherford Appleton Laboratory Email: [email protected]
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: [email protected]
201 Forrestal Road http://www.gfdl.noaa.gov/~smg
Princeton, NJ 08542-0308 USA
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
