Dear Alison and Stephen,
Thanks to both of you for good progress on this. I have added further
remarks to Stephen's email. I hope Jonathan and others will also review
the issues raised.
I apologize for responding here not only to the issue of
"standard_names" but also as to what should be saved for CMIP5, but this
is of immediate concern too.
Best regards,
Karl
Stephen Griffies wrote:
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.
I agree.
These are not variables (i.e., a physical quantities) and therefore do
not require standard_names CF does not control the vocabulary for
metadata that is not currently part of the convention. There are
efforts underway (e.g. METAFOR) that are attempting to standardize the
way experiments and models are described (documented) with metadata, but
for now you would be free to do what you want in recording the code
information.
Best,
Stephen
Pamment, JA (Alison) wrote:
Dear Stephen,
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
No. No standard name is needed for non-physical quantities.
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.
Yes, I think this is the way to go.
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.
I agree this is outside of what can be done at this time. I hope,
however, that for any grid, the data could be stored in a structured way
(either 1-d, 2-d, or 3-d array of numbers) and an approximate longitude
and latitude could be associated with each of these. If this is the
case (and I trust it is), then CF says how to store it along with the
longitudes and latitudes.
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.
I think this is incorrect because when sea ice is present we want the
pressure at the interface between sea ice and the ocean, not the atmos.
and ocean. I suggest:
pressure_at_the_top_of_the_sea or
pressure_at_the_sea_water_surface
but perhaps there are better words.
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).
More analogous is the "pressure thickness" of a sigma (or hybrid sigma
pressure) vertical coordinate system for the atmosphere. Here the
thickness can be calculated with well-know formulas, given the surface
pressure and the vertical coordinate information. The surface pressure
is, of course, a function of time. In the ocean models, would you have
to save a full 3-d ocean field every time-step to calculate the
thickness? We will have to prioritize among the following fields to save:
grid cell horizontal area
grid cell volume
grid cell mass
grid cell thickness
grid cell mass per unit area
grid cell density
We shouldn't store information that can be obtained by simple
multiplication or division from other quantities stored. What is the
minimum set recommended? [I apologize if this is already addressed in
the document, which I have at this point just begun to study.]
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?
The units in the standard_name table should be generic and consistent
(in this case "s"). For CMIP5 we can ask for any unit you like, and
although "year" is not a true unit since it varies from one year to the
next, I think in this case it might be o.k. (the approximation should be
good within a small fraction of a percent). What do others think?
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.
I don't see what "defined_by_mixing_scheme" adds. This does not make
the definition any more precise than simply ocean_mixed_layer_thickness.
Are there already other types of ocean_mixed_layer_thicknesses defined?
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.
I'm not particularly happy with y_overturning. Are there any better ideas?
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.
I do not like "temperature flux" expressed as heat flux. There must be
some terms used in engineering and physics that are better for this.
Ablation of material surfaces remove energy both by removing mass with a
certain amount of internal energy and by energy required to change the
phase. Is anyone familiar with the terminology?
Also, are you sure you want only "rainfall", rather than "precipitation"
, which includes water falling out of the atmosphere in the solid state
(e.g., snow). Perhaps you need to "snowfall" besides "rainfall" (because
the snow likely melts when it hits the ocean with the resultant latent
heat transfer), but I didn't see mention of "snow" on the list.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
