Dear Jonathan,
Thank you very much for your painstaking examination of these suggested
CF standard names. I apologise for the delay in replying, but (as you
know) I've been away.
Detailed responses follow. Generally, we're happy with your
suggestions.
On Wed, 2008-07-16 at 18:43 +0100, Jonathan Gregory wrote:
> Dear Ian and Dan
>
> Thanks for taking the time to compile this list. I agree with you that it
> would be good for NEMO netCDF output to be described by standard names. Are
> all these names actually required for output fields that NEMO produces?
Sadly, yes: these are what you get by default. I haven't bothered
specifying standard names for optional fields.
> Standard names need to have "canonical units"
> i.e. indicating the physical dimension. I have added what I suppose these to
> be in the list below but please correct me and fill in.
Thank you. (Units were in my Word version of the proposal, but left off
the email.)
> > (T.1) upward_water_flux_from_ocean_to_sea_ice kg m-2 s-1
> > ---------------------------------------------
> > The water flux out of the ocean to the sea ice which results from the
> > melting or freezing of sea ice.
>
> This and following names point out a problem with the existing name
> water_flux_into_ocean, which includes the flux due to sea-ice processes. Its
> definition explicitly says it's the flux into the sea-water. But the sea-ice
> is really, or at least arguably, part of the ocean, so this is unclear or
> inconsistent. You use "ocean" here in the same same sense of the liquid. I
> think we should clear up this confusion by renaming
> water_flux_into_ocean
> water_flux_into_ocean_from_rivers
> water_volume_transport_into_ocean_from_rivers
> wind_mixing_energy_flux_into_ocean
> and Martina's proposed name
> water_flux_into_ocean_without_flux_correction
> by replacing "ocean" with "sea_water". Then I would suggest your name could be
> water_flux_out_of_sea_water_due_to_sea_ice_thermodynamics
> There is no need for "upward" if you have "out of" (or "from") and the
> due_to phrase is used in other names.
I agree that changing ocean --> sea_water resolves the confusion, and am
happy with
water_flux_out_of_sea_water_due_to_sea_ice_thermodynamics.
>
> > (T.2) upward_water_flux_from_ocean_due_to_PME kg m-2 s-1
> > ---------------------------------------------
> > The evaporation out of the ocean minus the precipitation into it.
>
> I think this is the same as the existing name surface_upward_water_flux (over
> the ocean) isn't it?
>
Yes; thanks. I'll remove from list.
> > (T.3) upward_water_flux_out_of_ocean_affecting_SSH kg m-2 s-1
> > --------------------------------------------------
> > The volumetric freshwater leaving the sea water as a result of
> > precipitation, evaporation, river outflow and any water flux correction
> > (s) that may have been applied.
>
> This flux is the one which alters the mass of the ocean (=water+ice). It is
> the same as -water_flux_into_sea_water except that it does not include the
> sea-ice processes. Is that right?
Exactly!
> If so, I suggest
> water_flux_out_of_sea_ice_and_sea_water
Yes, I think that makes sense: it's flux_out_of_sea-water (which
includes seawater to ice flux) - that flux_into_sea-ice =
flux_out_of_sea-water + flux_out_of_sea-ice =
water_flux_out_of_sea_ice_and_sea_water, as you say.
> In your description you say "volumetric", though. Is that really what you
> mean i.e. is it m s-1 rather than kg m-2 s-1? Is it liquid water equivalent
> if so?
No, it's a mass flux (in kg/m2/s). I should have put "volumetric" in
quotes - I was just trying to emphasise that this is the one that's used
in d(SSH)/dt rather than d(SSS)/dt (which includes the sea-ice fluxes,
and is T.5). I'll remove volumetric from the description.
>
> > (T.4) water_flux_out_of_ocean_to_rivers kg m-2 s-1
> > ---------------------------------------
> > This is -1 times the quantity with the existing standard name of
> > water_flux_into_ocean_from_rivers.
>
> That is logical but strikingly unphysical :-) and therefore it may be better
> to spell it out as
> minus_one_times_water_flux_into_sea_water_from_rivers
OK by me. As I said in the intro, I think it's preferable to packing
the data with a scale_factor of -1.
>
> > (T.5) upward_water_flux_out_of_ocean_affecting_SSS kg m-2 s-1
> > --------------------------------------------------
> > The water flux out of the ocean affecting SSS is the
> > "concentration/dilution" freshwater leaving the sea water as a result of
> > precipitation, evaporation, river outflow, sea ice effects and any water
> > flux correction(s) that may have been applied.
>
> If I understand correctly, this is the same as -water_flux_into_sea_water
> (currently -water_flux_into_ocean), isn't it? If so I would call it
> water_flux_out_of_sea_water
> which contrasts with T3.
Yes, I agree. And then T1, T3 and T5 hang together nicely.
>
> > (T.6) downward_salt_flux_into_ocean_across sea_surface
> > ------------------------------------------------------
> > The sea surface salt flux deriving from a concentration/dilution water
> > flux (5 above).
>
> Is it really a salt flux (kg m-2 s-1) or it is a salinity flux (PSU m s-1)?
> If it is a salt flux, it isn't a physical one, I guess, so we should make that
> explicit by including some such word as "equivalent". Then I would try to make
> it correspond somehow to T5.
>
It is a virtual salt flux (in kg/m2/s), just given by T5 * SSS. So I
suggest
equivalent_salt_flux_out_of_sea_water. Do you agree?
> > (T.7) ocean_mixed_layer_thickness_defined_by_eddy_diffusion_coefficient m
> > -----------------------------------------------------------------------
> > The base of the mixed layer defined by eddy diffusion coefficient is the
> > level at which this diffusivity differs from its surface value by a
> > certain amount (specified by a scalar coordinate).
>
> As in Martina's and other existing names, this should be diffusivity rather
> than diffusion_coefficient. Is it tracer_diffusivity or momentum_diffusivity?
> What is meant by "eddy" here? - is "eddy" necessary?
Happy with diffusivity rather than diffusion_coefficient.
You're right, "eddy" not necessary, and in view of GM terms later,
probably best to suppress.
On thing I omitted to say is that this uses the z-cmpt of the tracer
diffusivity (ie Kzz in the tensorial formulation). I therefore suggest
ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity
(In the code this is called the "turbocline depth", which is evocative
but imprecise.)
>
> > (T.8) surface_heat_flux_due_to_relaxation W m-2
> > -----------------------------------------
> > The heat flux applied at the sea surface in order to restore the sea
> > surface temperature to some specified reference value (specified by a
> > scalar coordinate).
>
> This needs "downward" after "surface" to specify the sign. "surface" means
> the bottom of the atmos, but this is presumably applied to sea_water (not
> the sea_ice surface). In that case, it might be better to treat it like the
> water fluxes and call it
> heat_flux_into_sea_water_due_to_relaxation
>
Sounds good.
> > (T.9) surface_water_flux_due_to_relaxation kg m-2 s-1
> > ------------------------------------------
> > The surface water flux applied at the sea surface in order to restore
> > the sea surface salinity to some specified reference value (specified by
> > a scalar coordinate).
>
> Following T8 this would be
> water_flux_into_sea_water_due_to_relaxation
> and that would be consistent with the other water_flux names, which is nice.
Agreed, except that this term is +ve upward (it's added to E-P), so we
actually need
water_flux_out_of_sea_water_due_to_relaxation.
> Do you think we should include "relaxation" in the definition of the general
> water_flux_into_sea_water as well as flux correction? Or could we say that
> "relaxation" is actually a kind of flux correction?
You're more experienced in this than me, Jonathan, but the CF standard
name table says
"Flux correction is also called "flux adjustment"" and the AMS glossary
defines:
flux adjustment?In climate modeling, the practice of modifying the
fluxes (of heat and water) between the atmosphere and ocean in coupled
atmosphere?ocean models.
This modification is designed to minimize the climate drift that occurs
during model integration. These flux adjustments are typically a
function of location and season.
To me, the (Haney/Newtonian) relaxation used in NEMO is more general (eg
used in standalone ocean models) and (to court controversy!) arguably
more physically based. So for my money, "relaxation" is more than just
a special case of "flux correction". But I'm open to persuasion. If we
think it is different, then I think it probably ought to be included in
the defns of water_flux, because these relaxation terms _are_ included
in the NEMO output fields.
Perhaps we could be more specific, though, and talk about
newtonian_relaxation? (I don't like haney_relaxation, as it's applied
to SSS too.)
> > (T.10) surface_salt_flux_due_to_relaxation
> > ------------------------------------------
> > The surface salt flux applied at the sea surface in order to restore the
> > sea surface salinity to some specified reference value (specified by a
> > scalar coordinate).
>
> Similar comment to T6: is it really a salt flux? Is it equivalent to T9?
>
Again, it's just T9*SSS, so
equivalent_salt_flux_into_sea_water_due_to_relaxation
would seem to be appropriate. Do you agree?
> > (T.11) ocean_equivalent_rigid_lid_surface_height m
> > ------------------------------------------------
> > This is the ocean surface pressure derived using a rigid lid
> > approximation, expressed as an equivalent sea surface height.
>
> In data for CMIP3, we called this
> sea_surface_height_above_geoid
> just as if it had been obtained from a free surface. Do you need to specify
> explicitly it was inferred from the rigid-lid pressure?
>
I don't know - NEMO has rigid lid and free surface options. Mightn't it
be ambiguous if different things (in different runs) were given the name
standard_name? How about
rigid_lid_equivalent_sea_surface_height_above_geoid?
> > (T.12)
> > ocean_mixed_layer_thickness_in_model_levels_defined_by_sigma_theta 1
> > -------------------------------------------------------------------------
> > This quantity (the "bowl index") is the base level of that part of the
> > upper ocean which is considered well-mixed, expressed in terms of model
> > levels.
>
> I think this is analogous to existing names of the form
> model_level_number_at_SPECIAL_LEVEL so I would suggest
> model_level_number_at_base_of_ocean_mixed_layer_defined_by_sigma_theta
>
OK; thanks.
> > (T.13) thermocline_depth m
> > ------------------------
> > The depth of the maximum vertical gradient of sea water potential
> > temperature.
>
> This would benefit from ocean_ in front. But is this really *the* definition
> of the thermocline depth? I suspect "thermocline depth" can be understood in
> various ways. If so, something more explicit might help.
>
Fair enough - I'm sure you're right that thermocline means different
things to different people. How about
ocean_depth_at_maximum_upward_derivative_of_sea_water_potential_temperature?
> > (T.14) isotherm_depth m
> > ---------------------
> > The depth (if it exists) at which the sea water potential temperature
> > equals some specified value, which would be specified as a scalar
> > coordinate.
>
> This also needs ocean_ in front.
>
Or how about
ocean_depth_at_specified_sea_water_potential_temperature?
Or even simply
ocean_depth,
with a coordinate of sea_water_potential_temperature? Or is that too
likely to clash with a coordinate variable of the same name?
I'm happy with ocean_isotherm_depth, however.
> > (T.15) ocean_heat_content J
> > -------------------------
> > The (assumed constant) specific heat capacity times density of sea water
> > multiplied by the integral from z1 to z2 of sea water potential
> > temperature wrt depth. Following CF rules, the data variable needs to
> > have an axis for depth specifying [z1, z2] as bounds. How is this done
> > in practice? And is "ocean_heat_content" a sufficiently unambiguous
> > name? How, for instance, would we distinguish between this quantity and
> > the equivalent heat content calculated using the in situ density and
> > heat capacity?
>
> The depth range is specified by giving the variable a scalar coordinate
> variable of depth, or a dimension of depth with size one and a coordinate
> variable, and then in either case attaching a bounds variable to the
> coordinate variable.
I see; thank you.
> Your concerns about ambiguity worry me as well. We
> already have a standard name of
> ocean_integral_of_sea_water_temperature_wrt_depth
> so perhaps it would be safer to be explicit about the heat content thus:
> ocean_integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat
> What do you think?
>
Well, it's better than my fully explicit idea of
product_of_sea_water_density_and_sea_water_specific_heat_capacity_and_ocean_integral_of_sea_water_potential_temperature_wrt_depth! But I still think "_expressed_as_heat" is a little ambiguous, as it's not clear whether the conversion is done by multiplying by some (nominal) constant value of (rho*cp), or by some kind of mean value of the actual rho*cp, or mean(rho)*mean(cp), or ...
Strictly, I think we need to quote the exact formula for quantities like
this, in the same way that the standard_names and formula_terms do for
vertical coordinates. Perhaps this idea could be extended? But that's a
bigger issue. For now, I'm happy with
ocean_integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat
(or maybe
ocean_integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat_content?).
By the way, it's only extensive in depth, so the units are J m-2.
> > (T.16) surface_sea_ice_temperature K
> > ----------------------------------
> > Temperature of surface of sea ice.
>
> This doesn't need a new name; it should just be surface_temperature for the
> sea-ice portion of the box, which is specified using "where" in cell_methods
> (according to the ticket which I hope will soon be agreed).
>
OK, thanks. I didn't know about the "where" construct.
> > (T.17) sea_ice_albedo 1
> > --------------------
> > Albedo of sea ice.
>
> OK. I think this one does need its own name because it's a material property.
>
> > (U.1) x_sea_water_velocity m s-1
> > --------------------------
> > The sea water velocity in the x-direction.
>
> We already have sea_water_x_velocity
>
Sorry; missed that.
> > (U.2) x_sea_water_velocity_due_to_eddies m s-1
> > ----------------------------------------
> > Eddy-induced velocities are a feature of some parameterisations of
> > lateral diffusion in the ocean.
>
> Is that the same as bolus transport (GM)? We have names for bolus velocity
> components already, and the analogous one would be
> bolus_sea_water_x_velocity
Yes, Eddy-induced velocities = Bolus, so we can call it that.
>
> > (U.3) x_derivative_of_ocean_surface_pressure Pa m-1
> > --------------------------------------------
> > (d/dx) of the ocean surface pressure, keeping the other horizontal
> > coordinate (y, presumably) constant.
>
> x_derivative is fine, and I think we should note it in the standard name
> guidelines.
It is! The guidelines talk about component_derivative and allow
component=x (with a suitable comment).
Is Pa m-1 a better unit than N m-3?
> What is ocean_surface_pressure (air, rigid-lid, something else)?
>
It's the one obtained when using a rigid lid, so perhaps
x_derivative_of_ocean_equivalent_rigid_lid_surface_pressure would be
better?
> V1-3 as U1-3
>
Ditto.
> > (W.1) upward_sea_water_velocity_due_to_eddies m s-1
> > ---------------------------------------------
> > Eddy-induced velocities are a feature of some parameterisations of
> > lateral diffusion in the ocean. =
>
> See U2. Is this bolus_upward_sea_water_velocity, which exists already?
Yep.
> > (W.2) upward_sea_water_diffusivity_due_to_eddies m2 s-1
> > ------------------------------------------------
> > The effect of eddies on the vertical diffusivity of sea water.
>
> diffusivity doesn't have a direction, does it, so upward->vertical. Is this
> heat_diffusivity or tracer_diffusivity? What are eddies?
OK; I wasn't aware of the distinction between upward & vertical.
I thought heat_diffusivity = tracer_diffusivity? Perhaps you were
distinguishing (see later) between mom diff & tracer diff? In which
case, it's the latter.
I said "due_to_eddies" because that's in the long_name, and I thought it
was the contribution from the GM bolus velocity. However, looking in
the code, this quantity is just the overall tracer Kzz, so I think we
just want
vertical_sea_water_tracer_diffusivity.
But (see W6 below), it may be better to be specific and call this
vertical_sea_water_temperature_diffusivity.
>
> > (W.3) upward_sea_water_diffusivity_due_to_convection m2 s-1
> > ----------------------------------------------------
> > The enhanced diffusivity that is sometimes used to model the effect of
> > convective mixing on tracers in the ocean.
>
> Like W2 re upward and tracer.
OK - vertical_sea_water_tracer_diffusivity_due_to_convection it is.
>
> > (W.4) upward_sea_water_viscosity_due_to_eddies m2 s-1
> > ----------------------------------------------
> > The effect of eddies on the vertical viscosity of sea water.
>
> Like W2 re upward and eddies. viscosity->momentum_diffusivity, as in existing
> names (if indeed it is m2 s-1) since viscosity has other dimensions.
>
I can't see anywhere in the CF docs that viscosity always means the
dynamic visc (kg/m2/s) rather than the kinematic visc (=dyn
visc/density, in m2/s), but I'm happy to change
diffusivity --> tracer_diffusivity and
viscosity --> momentum_diffusivity
throughout if that makes it consistent.
So: vertical_sea_water_momentum_diffusivity.
> > (W.5) upward_sea_water_viscosity_due_to_convection m2 s-1
> > --------------------------------------------------
> > The enhanced viscosity that is sometimes used to model the effect of
> > convective mixing on momenta in the ocean.
>
> Like W2 re upward. Like W4 re viscosity.
>
So: vertical_sea_water_momentum_diffusivity_due_to_convection.
> > (W.6) upward_salt_diffusivity_due_to_eddies m2 s-1
> > -------------------------------------------
> > The effect of eddies on the vertical diffusion of salinity.
>
> Like W2 re upward and eddies.
>
This is a bit tricky. In the absence of double diffusive processes, T
and S have the same diffusivities - the
vertical_sea_water_tracer_diffusivity in W2. But when DD is present, the
two diffusivities differ, and W2 is really
vertical_sea_water_temperature_diffusivity.
In this case, NEMO also outputs W6, which I suggest should be called
vertical_sea_water_salinity_diffusivity.
> > (W.7) upward_sea_water_diffusivity_due_to_lateral_mixing m2 s-1
> > -------------------------------------------------
> > The vertical component of the diffusivity of sea water due to lateral
> > mixing. (This could appear in formulations of lateral diffusivity in
> > which "lateral" does not mean "iso-level", eg isopycnal diffusivity
This is the zz component of the lateral diffusivity of tracer in sea
water, which comes into play when "lateral" plane and the xy-plane do
not coincide. It's more numerical than physical, I think, and it's
definitely not the vertical (diapycnal) diffusivity. I suggest
vertical_part_of_lateral_sea_water_tracer_diffusivity
("component" a bit confusing)
or perhaps
vertical_sea_water_tracer_diffusivity_due_to_lateral_mixing,
but I'm struggling to give such an abstract quantity a snappy title!
Any better ideas?
> > (W.8) upward_sea_water_diffusivity_due_to_lateral_mixing_due_to_eddies m2 s-1
> > ---------------------------------------------------------------
> > The vertical component of the diffusivity of sea water due to the eddy-
> > induced component of lateral mixing.(This could appear in formulations
> > of lateral diffusivity in which =B4lateral=A1 does not mean =B4iso-level=A1=
> > , eg
> > isopycnal diffusivity.) Eddy-induced velocities are a feature of some
> > parameterisations of lateral diffusion in the ocean.
>
> Does NEMO output components of diffusivity? Components of flux seem more
> physical to me.
I agree, but yes, it does.
Actually, looking more closely in the code and at the standard_name
table, W8 is just
ocean_isopycnal_layer_thickness_diffusivity
(ie the GM diffn coeff), which already exists as a standard name.
>
> > (G.1) magnitude_of_derivative_of_distance_wrt_x_coordinate
> > ----------------------------------------------------------
> > Known in differential geometry as a scale factor, this quantity is |
> > (dr/di)jk|. It is a measure of the gridblock spacing in the x-
> > direction.
>
> What is x_coordinate? Is it an index? I think we should record a new standard
> name guideline for "magnitude" of a scalar, meaning "absolute value of".
>
It is an index in this case, so perhaps
magnitude_of_derivative_of_distance_wrt_x_index
or
magnitude_of_derivative_of_distance_wrt_x_coordinate_index
would be better?
magnitude_of_derivative_of_distance_wrt_model_x_coordinate_number
would be closer to the (new) G.3 proposal below.
In this case, magnitude does mean magnitude of a vector: in the
expression |(dr/di)jk|, dr is the vector displacement between the points
r(i+di,j,k) and r(i,j,k) in 3D space.
> > (G.2) magnitude_of_derivative_of_distance_wrt_y_coordinate
> > ----------------------------------------------------------
> > Known in differential geometry as a scale factor, this quantity is |
> > (dr/dj)ik|. It is a measure of the gridblock spacing in the y-
> > direction.
>
> As G1.
>
Ditto.
> > (G.3) magnitude_of_derivative_of_distance_wrt_z_coordinate
> > ----------------------------------------------------------
> > Known in differential geometry as a scale factor, this quantity is |
> > (dr/dk)ij|. It is a measure of the gridblock spacing in the z-
> > direction.
>
> As G1. If z_coordinate is an index, is it the same as model_level_number?
Yes, so: magnitude_of_derivative_of_distance_wrt_model_level_number is
probably better.
(Strictly speaking, one could quibble about the difference between the
discrete model_level_number k and the (implicitly assumed) continuous
variable k needed to calculate dr/dk, but let's not.)
>
> > (G.4) direction_of_x_grid_wrt_east degree
> > ----------------------------------
> > This quantity is the angle between due East and (dr/di)jk. It could be
> > used for rotating vector fields between model space and latitude-
> > longitude space.
>
> "direction" has a restricted meaning in standard names. To avoid that and to
> be explicit about the sign, could we call this
> angle_of_rotation_from_east_to_x
That sounds good. Would the usual convention that
anticlockwise=positive apply automatically, or would it need to be
explicitly stated in the defn?
> if that is correct?
>
> > (G.5) direction_of_y_grid_wrt_east degree
> > ----------------------------------
> > This quantity is the angle between due East and (dr/dj)ik. It could be
> > used for rotating vector fields between model space and latitude-
> > longitude space.
>
> Like G4.
Ditto.
>
> > (G.6) cell_area m2
> > ---------------
> > The horizontal area of a gridcell. See Sec 7.2 of CF documentation.
> > Since this can be associated with a variable by means of cell_measure =3D
> > area: attribute, it doesn't need a standard name, being considered part
> > of the variable's metadata. However, we don't think there's any harm in
> > proposing such a standard name. Comments?
>
> I think it's OK.
>
But I thought you said (email to Karl Taylor 27/6/08) that on balance
you preferred simply "area"? I don't really mind, but I prefer
cell_area (or gridcell_area) because it fits more naturally with
sea_ice_area, sea_area etc. I understand that cell_area is purely
numerical and that the others are physical, but ... so what?
> > (G.7) ocean_thickness_in_model_levels 1
> > -------------------------------------
> > The depth of the ocean expressed in model levels.
>
> I would call this model_level_number_at_sea_floor. The definition could note
> that it does not have to be integer.
OK, model_level_number_at_sea_floor it is.
Am I right in thinking that the extension of this idea, to a proposed
change of the CF cell_measures attribute, as described in our original
email would need a trac ticket raised, with a sponsor etc?
Thanks again for all your help on this. I suggest we go round one more
iteration loop and then I propose a revised list of standard_names (with
units!)
Regards,
Ian and Dan.
--
Ian Culverwell B-2-81 Ocean and Sea Ice Modelling
Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 884017 Fax: +44 (0)1392 885861
E-mail: ian.culverwell at metoffice.gov.uk http://www.metoffice.gov.uk
Dan Bernie
HadGEM Physical Processes and Coupling Scientist
Met Office Hadley Centre, FitzRoy Road, Exeter, EX1 3PB
Tel: +44 (0)1392 884862 Fax: +44 (0)1392 885681
E-mail: dan.bernie at metoffice.gov.uk http://www.metoffice.gov.uk
Met Office climate change predictions can now be viewed on Google Earth
http://www.metoffice.gov.uk/research/hadleycentre/google/
Received on Fri Jul 25 2008 - 05:47:07 BST
