Dear Stephen, Karl, Jonathan, John, Nan and Roy,
Thanks all for your comments on these names. Please see below for the
status of the names still under discussion. At the end of this message
is a complete list of the new names that we have agreed so far from this
set of proposals.
Stephen wrote:
> >
> > 1.1 equation of state
> > 1.2 seawater freezing
>
> 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.
>
Karl has pointed out that strictly speaking these formulae are not
physical variables and so don't require standard names, while John
Graybeal has suggested that standard names for non-physical quantities
would be a useful addition to CF metadata. Section 3.3 of the CF
conventions discusses standard names and does indeed concentrate on
their use for describing physical quantities. In fact, the one line
description of a standard name is "The name used to identify the
physical quantity." If we adhere strictly to this definition then I
agree that formulae, whether expressed in FORTRAN or otherwise, do not
need standard names. Therefore, these two names will not be added to
the table.
Karl mentioned the METAFOR project whose aim is to develop metadata
conventions for describing models in detail. A possible route for
future development would be to allow CF metadata to point to a METAFOR
record and thus to a full description of the model used. However, that
clearly won't be possible on the timescale of the CMIP5 exercise and is
something for future discussions.
Nan has suggested that algorithms could be stored as attributes (either
global or attached to a variable) and also that a set of 'standard
terms' to identify common algorithms could be established. Again, an
extension to CF would be required if we were to opt for this route.
1.5 grid specification (lengths, areas) with units of m and m2.
Stephen wrote:
>
> 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.
>
Clearly, if the requirement is to archive complete specifications of a
number of complex grids this would require extension of the CF
conventions. As you say, this issue is well beyond the scope of a
standard names discussion.
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.
> >
Jonathan wrote:
> The document intends to use the existing name of region, but some of
the possible values for a region variable > are proposals for addition
to the list of standard region names.
>
Jonathan, please can you clarify whether you would like me to handle
proposals for new region names alongside standard names or is this a
matter for consideration by the conventions committee?
Nan has pointed out that that there are some GCMD regions missing from
the current CF region list:
> Reviving an old topic, the CF region names list is now out of date;
there are 7 or 8 names on the GCMD list
> that have not been added to the CF document. They are:
> Bay Of Bengal
> Bay Of Fundy
> Davis Straight
> Georges Bank
> Grand Banks
> Gulf Of Maine
> Gulf Of St Lawrence
> And I'm not sure if you'd want to include it, but they list "South
China And Eastern Archipelagic Seas" too.
Roy, in his postings
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009/002690.html and
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009/002691.html has
drawn attention to the SeaVox ontology for water body names and the IHB
Undersea Feature Names as worthy of note when the CF regions are
updated.
> >
> > 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.
>
OK, thanks. Units of dbar are agreed. Please see the discussion of 2.3
for my comments regarding the name itself.
>
> > 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.
Karl wrote:
> 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.
Stephen wrote:
> 1/ As Jonathan says in his email, the desire is to have a measure of
the total pressure applied to the liquid
> ocean surface, including sea ice and atmosphere loading. If "surface"
is interpreted as the liquid ocean
> surface, then the name surface_sea_water_pressure is fine. But to be
extra clear, your suggestion
> pressure_at_the_sea_water_surface is appealing. Likewise, I suggest
changing sea_water_pressure_at_sea_floor
> to just the simpler pressure_at_sea_floor, since the desired pressure
includes that from seawater as well as
> the media above the liquid ocean.
>
> In summary, I recommend the following two field names that are
sufficient to bound the ocean pressure field:
>
> pressure_at_the_sea_water_surface
> pressure_at_sea_floor
> Jonathan wrote:
> I would prefer keeping the sea_water in sea_water_pressure:
> > sea_water_pressure_at_the_sea_water_surface
> > sea_water_pressure_at_sea_floor
> It might seem redundant in this context but it corresponds to the
standard name of sea_water_pressure,
> analogous to air_pressure. That means the pressure that exists in the
medium of sea water. It doesn't imply
> that it is caused only by overlying sea water.
Thank you all for clarifying the definitions of the proposed names. I
note that Stephen has accepted Jonathan's most recent suggestions for
these names. Thus, sea_water_pressure_at_sea_water_surface (note I have
omitted the 'the') and sea_water_pressure_at_sea_floor are agreed.
The standard name table entry for sea_water_pressure currently contains
no definition. I will add Jonathan's explanation of the name at the
next update of the table.
2.10 mass_of_sea_water_per_unit_area.
Karl wrote:
> We distinguish currently between atmosphere_mass_per_unit_area and
atmosphere_mass_of_air_per_unit_area (which > only accounts for the
gaseous constituents, not, for example, precipitation). For the oceans
I think Stephen
> wants to save the total mass, i.e., seawater_mass_per_unit_area.
Stephen wrote:
> For non-Boussinesq models, I wish to have the mass of seawater in a
grid cell, per horizontal area of the cell.
> This mass includes all dissolved tracers, as well as liquid water,
hence the name "seawater mass". I do
> not have a strong feeling for whether
"mass_of_sea_water_per_unit_area"
> is preferable to "seawater_mass_per_unit_area", as they both seem to
refer to the same thing. In my updated
> report, it reads "mass_of_sea_water_per_unit_area". Please advise if
you wish this name to change.
This raises a subtle point. The direct analogy of
atmosphere_mass_per_unit_area would actually be ocean_mass_per_unit_area
because both would then refer to the large-scale body, rather than a
local property of the medium. In standard names we make a distinction
between the terms 'atmosphere' and 'in_air' and similarly between
'ocean' and 'sea_water'. Thus we talk about the ocean mixed layer but
the velocity of sea water. Karl's point about the order of the wording
is also a fair one. I think the choice is between
ocean_mass_per_unit_area or sea_water_mass_per_unit_area and we should
probably choose the former to be consistent with the atmosphere name.
What do others think?
N.B. If we opt for ocean_mass_per_unit_area then for consistency I think
we should also change proposal 2.1, sea_water_mass, to ocean_mass (kg).
2.11 cell_thickness; m.
Stephen wrote:
>
> 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).
>
Karl wrote:
> 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.]
Stephen wrote:
> There is presently no minimum set of grid variables discussed in the
report. The resolution of what is a
> minimal set goes beyond this email list. But in the process of
thinking about this set, it is important to
> remember that the vertical thickness and mass per unit area are in
general time dependent three dimensional
> fields.
Jonathan wrote:
> I agree also that we need ways to describe more grid-information for
CMIP5 (I assume this will come in Balaji's
> proposal). But even without adding it to cell_measures, we could
introduce the standard_name of cell_thickness.
I take Stephen's point that thickness can vary with time and therefore
making it a cell_measure would not be a satisfactory approach. The name
cell_thickness has been proposed in the past (in chemistry and ocean
discussions) although we never seem to have reached a final decision on
it. It has also cropped up again recently in the atmospheric dynamics
names proposed by Martin Schultz. Judging by the number of times it has
been proposed, there is clearly a popular and pressing demand for this
name! The name cell_thickness is accepted.
>
>
> > 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.
> >
> >
Stephen wrote:
>
> The nearly universal unit for age in oceanography is years. Can we
> make
> an exception here?
Karl wrote:
> 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?
Jonathan wrote:
> I think year is acceptable, if inaccurate, for the age of sea water.
It depends on analysis programs treating
> it properly. Perhaps the CMIP5 doc can say exactly how this quantity
is to be evaluated and interpreted in
> years.
Jonathan, just to clarify, are you suggesting that years makes sense as
a canonical_unit?
2.18 moles_per_unit_mass_of_cfc11_in_sea_water; mol kg-1.
This name is agreed.
>
>> 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.
Karl wrote:
> 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?
There are already six ocean_mixed_layer_thickness names, as follows:
ocean_mixed_layer_thickness
ocean_mixed_layer_thickness_defined_by_mixing_scheme
ocean_mixed_layer_thickness_defined_by_sigma_t
ocean_mixed_layer_thickness_defined_by_sigma_theta
ocean_mixed_layer_thickness_defined_by_temperature
ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity
As you will see, this list includes the newly proposed name - apologies
for not having spotted it before! The definition of
ocean_mixed_layer_thickness_defined_by_mixing_scheme is "The ocean mixed
layer is the upper part of the ocean, regarded as being well-mixed. The
base of the mixed layer defined by the mixing scheme is a diagnostic of
ocean models." The definition of ocean_mixed_layer_thickness is "The
ocean mixed layer is the upper part of the ocean, regarded as being
well-mixed. Various criteria are used to define the mixed layer; this
can be specified by using a standard name of
ocean_mixed_layer_defined_byX." I wonder if in practice these two are
really the same quantity, as Karl suggests. If so, I would suggest
retaining the name ocean_mixed_layer_thickness and making
ocean_mixed_layer_thickness_defined_by_mixing_scheme an alias of it.
Can anyone comment on whether these names describe distinct quantities?
> > 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.
>
OK, thank you for the clarification. I will ensure that this difference
is made clear in the definition.
>
> > 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.
>
Thanks for the clarifying the definition.
Karl wrote:
> I'm not particularly happy with y_overturning. Are there any better
ideas?
I assume the reason for using the term 'y_overturning' was to express
the fact that in this case the streamfunction is calculated on the
model's native horizontal grid rather than a lat-lon grid. Given that
in standard names we usually make the distinction between grids by use
of 'x_' and 'y_' terms, I think the original proposal makes sense. Does
anyone else wish to express a view on this? N.B. This also affects
proposal 3.10
ocean_y_overturning_mass_streamfunction_due_to_bolus_advection as the
names need to be consistent.
6.3 virtual_salt_flux_into_sea_water_from_rivers; kg m-2 s-1.
This name is agreed.
6.8 salt_flux_into_sea_water_from_rivers; kg m-2 s-1.
This name is agreed.
> > 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_w
> a
> > 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.
> >
I note that after some discussion these amended names were agreed. On
12 Jan 2009 Stephen wrote:
> >>
temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water
> >>
temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_wa
ter
> >>
temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water
>
> Fine
Thank you Stephen, Jonathan and Karl for the discussion of these names.
A question was raised during the discussion regarding the formula
defining the evaporation quantity. Karl asked whether it was correct to
define the quantity using evaporation rate or whether explicit water
mass fluxes should be used. Sorry if I missed something in the
discussion, but has this point been answered? Is everyone now agreed on
the above names and the definitions as given in Stephen's original
document?
Further to these heat flux names Karl wrote:
> 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.
>
Stephen wrote:
> Good point. We do request snowfall as a mass flux. But since we are
> measuring heat flux from mass transfer, relative to 0C, then snow
> falling at 0C will not contribute any heat transfer due to mass
> transfer. But as you say, it will cause heat transfer from latent heat
> of fusion. This latent heat term was missing in our original report.
> For this latent heat, I suggest the name
>
> heat_flux_into_sea_water_due_to_snow_thermodynamics
>
> analogous to the other fields of this sort from icebergs and seaice.
The additional name heat_flux_into_sea_water_due_to_snow_thermodynamics
(W m-2) is accepted.
7.5 heat_flux_into_sea_water_due_to_sea_ice_thermodynamics; W m-2. OK.
Karl wrote:
> In CMIP3 we collected upward_sea_ice_basal_heat_flux, which is a CF
standard name, which we described in CMIP3 > as "Compute the average
rate that heat flows up at the base of the sea ice (i.e., Watts) divided
by the
> average area of the grid cell covered by sea ice. This quantity
multiplied both by the average area covered by
> sea ice and by the length of the month should yield the total energy
flowing into the ice from below. Report
> as 0.0 in regions free of sea ice."
>
> Is that the same thing except for a factor that is the fraction of the
ocean covered by seaice?
Stephen wrote:
> The sea ice flux question awaits input from ice folks here, to see how
the new request compares to CMIP3.
It would be helpful to know if these names are closely related so that
the information can be included in the definitions.
7.6 heat_flux_into_sea_water_due_to_iceberg_thermodynamics; W m-2.
This name is agreed.
>
> > 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.
>
OK, thanks for the clarification.
Karl wrote:
>> 9.12
>>
ocean_kinetic_energy_dissipation_per_unit_area_due_to_vertical_friction;
W m-2. OK.
>
> I don't find this particularly enlightening. What distinguishes
> "vertical friction" for other friction?
>
Stephen wrote:
> Ocean models generally use lateral friction with a huge viscosity set
according to the needs of numerical
> stability constraints. In contrast, vertical friction uses a much
smaller viscosity that is more aligned with
> physical closures (though far from being derived from first
principles). In studying the kinetic energy
> budget in ocean simulations, it is very useful to know how much energy
is dissipated from horizontal friction,
> and how much is separately dissipated from vertical friction. It is
for this reason that we request saving
> energy dissipation from vertical friction separate from horizontal
friction.
> We ask for both terms. There are endnotes that detail the precise
nature of what is requested.
Thank you for the clarification. I will include this explanation when
the name is added to the table.
The list of agreed names and units now follows:
reference_sea_water_density_for_boussinesq_approximation; kg m-3
sea_water_pressure_at_sea_floor; dbar
sea_water_pressure_at_sea_water_surface; dbar
sea_water_volume; m3
square_of_sea_surface_height_above_geoid; m2
global_average_steric_sea_level_change; m
cell_thickness; m
square_of_sea_surface_temperature; K2
moles_per_unit_mass_of_cfc11_in_sea_water; mol kg-1
ocean_barotropic_mass_streamfunction; kg s-1
square_of_ocean_mixed_layer_thickness_defined_by_sigma_t; m2
upward_ocean_mass_transport; kg s-1
square_of_upward_ocean_mass_transport; kg2 s-2
ocean_mass_x_transport; kg s-1
ocean_mass_y_transport; kg s-1
ocean_meridional_overturning_mass_streamfunction; kg s-1
ocean_meridional_overturning_mass_streamfunction_due_to_bolus_advection;
kg s-1
ocean_heat_x_transport; W
ocean_heat_y_transport; W
ocean_heat_x_transport_due_to_bolus_advection; W
ocean_heat_y_transport_due_to_bolus_advection; W
ocean_heat_x_transport_due_to_diffusion; W
ocean_heat_y_transport_due_to_diffusion; W
water_flux_into_sea_water_from_icebergs; kg m-2 s-1
water_flux_into_sea_water_due_to_sea_ice_thermodynamics; kg m-2 s-1
virtual_salt_flux_into_sea_water_due_to_rainfall; kg m-2 s-1
virtual_salt_flux_into_sea_water_due_to_evaporation; kg m-2 s-1
virtual_salt_flux_into_sea_water_from_rivers; kg m-2 s-1
virtual_salt_flux_into_sea_water_due_to_sea_ice_thermodynamics; kg m-2
s-1
virtual_salt_flux_correction; kg m-2 s-1
salt_flux_into_sea_water_from_rivers; kg m-2 s-1
upward_geothermal_heat_flux_at_sea_floor; W m-2
heat_flux_into_sea_water_due_to_snow_thermodynamics; W m-2
heat_flux_into_sea_water_due_to_sea_ice_thermodynamics; W m-2
heat_flux_into_sea_water_due_to_iceberg_thermodynamics; W m-2
downwelling_shortwave_flux_in_sea_water; W m-2
surface_downward_x_stress_correction; Pa
surface_downward_y_stress_correction; Pa
ocean_vertical_tracer_diffusivity_due_to_background; m2 s-1
ocean_vertical_tracer_diffusivity_due_to_tides; m2 s-1
tendency_of_ocean_potential_energy_content; W m-2
tendency_of_ocean_potential_energy_content_due_to_tides; W m-2
tendency_of_ocean_potential_energy_content_due_to_background; W m-2
ocean_vertical_momentum_diffusivity_due_to_background; m2 s-1
ocean_vertical_momentum_diffusivity_due_to_tides; m2 s-1
ocean_vertical_momentum_diffusivity_due_to_form_drag; m2 s-1
ocean_kinetic_energy_dissipation_per_unit_area_due_to_vertical_friction;
W m-2
ocean_tracer_bolus_laplacian_diffusivity; m2 s-1
ocean_tracer_bolus_biharmonic_diffusivity; m4 s-1
ocean_tracer_epineutral_laplacian_diffusivity; m2 s-1
ocean_tracer_epineutral_biharmonic_diffusivity; m4 s-1
ocean_tracer_xy_laplacian_diffusivity; m2 s-1
ocean_tracer_xy_biharmonic_diffusivity; m4 s-1
tendency_of_ocean_eddy_kinetic_energy_content_due_to_bolus_transport; W
m-2
ocean_momentum_xy_laplacian_diffusivity; m2 s-1
ocean_momentum_xy_biharmonic_diffusivity; m4 s-1
ocean_kinetic_energy_dissipation_per_unit_area_due_to_xy_friction;W m-2
Best wishes,
Alison
------
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.
--
Scanned by iCritical.
Received on Tue Feb 10 2009 - 04:57:24 GMT
