Dear Jonathan,
Thanks as ever for your thoughts. Comments on remaining differences
follow.
On Thu, 2008-08-07 at 10:51 +0100, Jonathan Gregory wrote:
> Dear Ian and Dan
>
> Thanks for your email. I believe we agree on the following (omitting the
> descriptions for the sake of the overview).
>
> Rename:
>
> water_flux_into_ocean
> water_flux_into_ocean_from_rivers
> water_volume_transport_into_ocean_from_rivers
> wind_mixing_energy_flux_into_ocean
> water_flux_into_ocean_without_flux_correction (proposal agreed with Martina)
>
> by replacing "ocean" with "sea_water".
>
> Include Newtonian relaxation in the definitions of water_flux_into_sea_water,
> water_flux_out_of_sea_water (T5), water_flux_out_of_sea_ice_and_sea_water
> (T3), virtual_salt_flux_into_sea_water (T6).
>
> New names:
>
> T1 water_flux_out_of_sea_water_due_to_sea_ice_thermodynamics (kg m-2 s-1)
> T3 water_flux_out_of_sea_ice_and_sea_water (kg m-2 s-1)
> T4 minus_one_times_water_flux_into_sea_water_from_rivers (kg m-2 s-1)
> T5 water_flux_out_of_sea_water (kg m-2 s-1)
> T7 ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity (m)
> T8 heat_flux_into_sea_water_due_to_newtonian_relaxation (W m-2)
> T9 water_flux_out_of_sea_water_due_to_newtonian_relaxation (kg m-2 s-1)
> T12 model_level_number_at_base_of_ocean_mixed_layer_defined_by_sigma_theta (1)
> T13 depth_at_maximum_upward_derivative_of_sea_water_potential_temperature (m)
> T15 ocean_integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat_content (J m-2)
> T17 sea_ice_albedo (1)
> U2 bolus_sea_water_x_velocity (m s-1)
> U3 x_derivative_of_ocean_rigid_lid_pressure (N m-3)
> V2 bolus_sea_water_y_velocity (m s-1)
> V3 y_derivative_of_ocean_rigid_lid_pressure (N m-3)
> W2 vertical_sea_water_temperature_diffusivity (m2 s-1)
Amended following later email on 7/8/08 to
W2 vertical_sea_water_heat_diffusivity (m2 s-1)
> W4 vertical_sea_water_momentum_diffusivity (m2 s-1)
> W5 vertical_sea_water_momentum_diffusivity_due_to_convection (m2 s-1)
> W6 vertical_sea_water_salinity_diffusivity (m2 s-1)
Amended following later email on 7/8/08 to
W6 vertical_sea_water_salt_diffusivity (m2 s-1)
I'd suggest proposing
W9 vertical_sea_water_tracer_diffusivity (m2 s-1)
in anticipation of getting NEMO to output this when the T&S
diffusivities are the same, but I think Martina's suggestion
ocean_vertical_tracer_diffusivity (m2 s-1)
covers it already, n'est-ce pas?
> G4 angle_of_rotation_from_east_to_x (degree)
> G5 angle_of_rotation_from_east_to_y (degree)
> G6 cell_area (m2)
> G7 model_level_number_at_sea_floor (1)
>
> Others are either agreed to be equivalent to existing names, or discussed
> below (T6, T10, T11, W3, W7, G1-3).
>
> T3: This quantity includes rivers, flux adjustment and relaxation. Without
> these i.e. only the fluxes at the surface of the sea ice and sea water, the
> name would be surface_upward_water_flux, since "surface" means "bottom of
> atmosphere" in effect. We also agreed that T2 is surface_upward_water_flux,
> over the open ocean i.e. it is P-E where there is no sea-ice. These would be
> distinguished by cell_methods. T2 is "where ice_free_sea", but if sea-ice is
> included there is no need for "where" because it applies to the whole
> gridbox. You can also have "where sea_ice", which would mean the
> precipitation, evaporation and sublimation from the sea-ice surface.
Sorry Jonathan, I'm completely confused now. Haven't we agreed that
T2 surface_upward_water_flux (kg m-2 s-1)
and
T3 water_flux_out_of_sea_ice_and_sea_water (kg m-2 s-1)?
Are you saying we have to do any more to specify these quantities
(through the cell methods)? Sorry for being dense.
>
> T4: I agree with you that, though inelegant, this is preferable to using
> the scale_factor. That's intended for packing, not for defining the sign of
> the quantity.
>
> T6: In your email you explain this as just being -T5*SSS (I think I am right
> to put in minus, since T5 is upward, and your original proposal for T6 is
> downward).
No: E-P > 0 ==> dSSS/dt > 0, and T5 is water flux out of ocean (same
sign as E-P) while T6 is salt flux into ocean (same sign as dSSS/dt), so
T6 = T5*SSS. (In other words, as a vector eqn for fluxes, f(virtual
salt) = -SSS * f(freshwater), as you say, but the -sign is accounted for
by different ref dirns for the 2 fluxes.) I don't know why I suggested
virtual_salt_flux_out_of_sea_water (which would be -SSS*T5) when it
really is into the sea (as the original suggestion of
downward_salt_flux_into_ocean made explicit); anyway, I think we now
agree with
virtual_salt_flux_into_sea_water (kg m-2 s-1)
for T6=SSS*T5.
> This is related to the salinity flux, which is
> -T5*SSS/density. That being so, your word "virtual", which has the virtue of
> being often used, may be best to indicate it's not really a physical salt
> flux. So for consistency with T5 I would now propose
> virtual_salt_flux_into_sea_water (kg m-2 s-1).
>
> T8, T9. I agree with your insertion of "newtonian".
>
Jolly good.
> T10. Following T6, I would now suggest
> virtual_salt_flux_into_sea_water_due_to_newtonian_relaxation (kg m-2 s-1).
>
Agreed.
> T11. Things should have the same standard name if they are intended to be
> compared. They need different standard names if you want to distinguish them.
> So the choice depends on the application, to some extent. I think that
> sea_surface_height_above_geoid is OK for the quantity derived from the rigid
> lid, as used in CMIP3, but if you want to show where it comes from, my
> modified suggestion of yours would be
> ocean_rigid_lid_pressure_expressed_as_sea_surface_height_above_geoid. We don't
> currently have a standard name of ocean_rigid_lid_pressure but it might
> plausibly be proposed. We have other uses of "expressed as". What would you
> prefer?
>
I accept the point you're making, but I think a line needs to be drawn
somewhere, otherwise (for instance) we could call the virtual salt
fluxes in T6 & T10 plain "salt fluxes", so that they could be compared
with actual salt fluxes in another model that explicitly makes use of
them. So I would prefer a new name for this quantity, and
ocean_rigid_lid_pressure_expressed_as_sea_surface_height_above_geoid
seems admirably precise to me.
> T13. We haven't put "depth" in other "ocean depth" names so I've omitted
> it from your proposal.
>
OK.
> T14. We have a standard name of plain "depth" meaning distance below the
> surface, which is what you want, I think. It's fine to give it a coordinate of
> sea_water_potential_temperature. If there is another quantity with that
> standard name, they just have to have different variable names. Good solution!
> There is a symmetry about having both sea_water_potential_temperature with a
> coordinate of depth, and vice-versa. My only reservation is that the standard
> name of the data variable doesn't indicate it's in the ocean, but I think
> that's OK. The coord variable implies this, and anyway "depth" is really
> independent of medium.
>
Mmmm. Well, having convinced you of the wisdom of using depth(theta),
complementary to theta(depth), I'd still like to have new standard_name
of ocean_isotherm_depth (m), because (parochial UK Met Office point
coming up; other readers can stop reading here) we're going to use
standard names to map to STASH codes, and I think we'd probably want
different STASH codes for (say) isotherm depth and geopotential depth,
wouldn't we? Eg currently we have (in atmos)
16201 1 GEOPOTENTIAL HEIGHT ON THETA LEVELS
16202 1 GEOPOTENTIAL HEIGHT: PRESSURE LEVELS
16255 1 GEOPOTENTIAL HEIGHT ON RHO LEVELS
and these would all have a CF standard_name of geopotential_height.
Since the main reason for defining these standard_names is to set up
this mapping to STASH codes, it'd be easier to have a specific
standard_name for each such variable. So I'd still like
T14 ocean_isotherm_depth (m)
please.
> T15. "ocean" seems a bit unnecessary and it's only there to indicate the
> integral is through the whole depth of the ocean, as contrasted with a layer.
> We make this distinction in many standard names, however, and I'd like to get
> rid of it, but that should be a separate proposal.
>
Happy to drop "ocean", as it's almost always over the 0-300m layer, not
the full depth, and makes the standard_name shorter too!
> U3. A slight simplification of your latest version; I hope that's OK. N m-3
> and Pa m-1 are both fine, being equivalent!
>
Exactly. Your simplification is fine.
> W3. Is this also temperature rather than tracer?
>
No, I think it's both, even in presence of DD, ie
vertical_sea_water_tracer_diffusivity_due_to_convection (kg m-2 s-1).
> W4. You are right, we have not made this distinction; we have not used the
> word "viscosity" at all so far because of the potential ambiguity.
>
> W7. As alternative to introducing the term "lateral" we could perhaps call
> this xy, to mean the coordinate plane. In other contexts we use the word
> "horizontal" to mean this (as it usually is) but a vertical component of
> something horizontal would certainly be a mysterious concept!
Indeed. I like "xy", as it's unambiguous.
> Why do you
> prefer "part" to "component"?
Just a feeling that people may confuse this with the diapycnal component
of the full tensor diffusivity. And it's only the vertical cmpt of the
xy part, not of the full tensor. However, let's not quibble - your
suggestion below is excellent. Anyone likely to use such a quantity is
(hopefully!) likely to understand the ideas behind it.
> I think
> vertical_component_of_sea_water_tracer_xy_diffusivity would be intelligible.
>
> G1-G3. I like your suggestion of "coordinate index". That gives us
> magnitude_of_derivative_of_distance_wrt_x_coordinate_index (m)
> magnitude_of_derivative_of_distance_wrt_y_coordinate_index (m)
> magnitude_of_derivative_of_distance_wrt_model_level_number (m)
> but I wonder whether we might be better off with x_distance, y_distance
> and depth? Although this is repetition, "distance" is rather a vague word
> and that might clarify the picture. Since they are magnitudes it doesn't
> matter whether it is depth or height, and depth seems more intuitive for
> an ocean model. What do you think?
>
Well, I think
magnitude_of_derivative_of_distance_wrt_x_coordinate_index
is the same thing as
magnitude_of_derivative_of_x_distance_wrt_x_coordinate_index, but it's
still confusing, because people might think the 2nd means |d(r.ihat)/di|
(where || = mag of scalar), which I don't think it does. (I think it
means |ihat.dr/di|, which does indeed equal the first (which is |dr/di|
(where || = mag vector)).)
It's that little word "distance" that's causing the trouble. May I
suggest using the true definitions of the scale factors:
magnitude_of_partial_derivative_of_position_wrt_x_coordinate_index (m)
magnitude_of_partial_derivative_of_position_wrt_y_coordinate_index (m)
magnitude_of_partial_derivative_of_position_wrt_model_level_number (m)
I don't mind "location" instead of "position" - I couldn't find a
precedent for the use of either in the CF standard name table. The words
"partial_derivative" should make it clear that the other coord indices
are being held constant, which is what you were trying to make clear, I
think.
> G4. The sign convention anticlockwise=positive should be stated in the
> definition, as you say.
>
OK.
> G6. I did prefer "area" earlier but you have changed my mind.
>
OK.
> G7. Yes, you are right in thinking that the proposed change of the CF
> cell_measures attribute, as described in our original email would need a trac
> ticket raised, with a sponsor etc? This applies likewise to G1-G3, which
> could also be cell_measures.
>
OK; we'll try it out.
Regards, and thanks again,
Ian.
--
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
Met Office climate change predictions can now be viewed on Google Earth
http://www.metoffice.gov.uk/research/hadleycentre/google/
Received on Fri Aug 08 2008 - 10:23:22 BST
