Dear Alison
Thank you for your careful analysis and comments, and thanks to Steve for
responding quickly. I'm sorry, I'm colour-blind in emails (since I read and
write them in plain text).
> > c. sea_water_salinity_at_sea_floor (1e-3)
> > 'Salinity adjacent to the ocean bottom (at the deepest grid cell in a
> > model).'
> >
> > I assume this quantity is similar to the existing 'sea_surface_salinity'
> > which is one of the few names where, for historical reasons, we use 'sea
> > surface' to mean a near surface layer rather than the actual air-sea
> > interface. By analogy it is reasonable to say that the proposed quantity is
> > 'at_sea_floor' meaning a near floor layer. However, I'm not keen on
> > extending this use of defined surfaces to describe layers (and we have just
> > had a long conversation about this for the biogeochemistry names). If we
> > take the same approach with this name as with the biogeochemistry names I
> > think we could use the existing name sea_water_salinity and the depth (or
> > height above sea floor) of the layer would be supplied using a scalar
> > coordinate variable. Coordinate bounds should also be used to describe the
> > thickness of the layer.
> >
> > N. B. Although sea_water_potential_temperature_at_sea_floor has already
> > been added to the table, we should treat it consistently with the salinity
> > name. If we choose to use simply 'sea_water_salinity', then we should also
> > use 'sea_water_potential_temperature'. In that case sea_water_potential_temperature_at_sea_floor
> > would be turned into an alias of sea_water_potential_temperature.
> >
> > What do you think of this approach?
I think sea_floor is a "named" level, and this quantity is more like
surface_temperature than sea_surface_temperature, in being the salinity of the
water at the very bottom, next to the floor. The temperature is continuous
across the interface, so sea_water_temperature_at_sea_floor would equal the
temperature at the top of the solid sea-bed. Of course, salinity exists only on
the side of the water, but it's still a property of the water at the interface.
This is an idealised view. In practice, if you measured
sea_water_salinity_at_sea_floor, it would not be exactly at the floor, but
presumably you'd try to be close. In a GCM, it might be the salinity of the
lowest gridbox, because that's as low as you could get, unless you extrapolate
it or have a bottom BL. But in any case, the intention is to get to the bottom,
I believe because it's of interest wrt to benthic organisms.
> > 2. Integral quantities
> >
> > a. integral_wrt_depth_of_product_of_sea_water_density_and_potential_temperature
> > (kg C m-2)
> > 'Product of grid cell thickness with density and potential temperature,
> > summed over the depth of the ocean column. For Boussinesq models, density
> > is constant Boussinesq reference density (reference_sea_water_density_
> > for_boussinesq_approximation).'
> >
> > For consistency with the syntax of existing names the 'wrt_depth' should
> > come at the end, i.e. integral_of_product_of_sea_
> > water_density_and_potential_temperature_wrt_depth. The canonical units of
> > this quantity should be kg K m-2 (but it's fine to use Celsius in your
> > files because the UDUnits software used in CF can convert Celsius to
> > Kelvin). The wording of the definition also needs to be made consistent
> > with existing names.
>
> I am fine moving "wrt_depth" to the end.
>
> I wish to keep units using C rather than K. Here are the reasons. 1/ No
> ocean model uses K for its temperature field. 2/ For an ocean column that
> has changing thickness, it is not possible to convert heat content using K
> to that using C using offline time mean quantities. So throughout the
> ocean request (more on this below), we are requesting heat content and
> integrated temperature quantities to be based on degrees C.
Despite the guidelines, we have two existing standard names that start
integral_wrt_depth_of. I think that if X is a very long phrase, like
product_of_sea_water_density_and_potential_temperature, integral_wrt_depth_of_X
is easier to understand than integral_of_X_wrt_depth. So I'd suggest that these
are legitimate variants. The same applies to the other integral names.
I agree with Steve about degC, since we've done this with other quantities.
> > 3. Tendencies
> >
> > There are 21 proposed tendency names which follow three patterns as
> > follows:
> > tendency_of_sea_water_potential_temperature_expressed_as_heat_content[_due_to_PROCESS]
> > (W m-2)
> > tendency_of_sea_water_conservative_temperature_expressed_as_heat_content[_due_to_PROCESS]
> > (W m-2)
> > tendency_of_sea_water_salinity_expressed_as_salt_content[_due_to_PROCESS]
> > (kg m-2 s-1).
> >
> > In each case PROCESS is one of the following: advection,
> > parameterized_mesoscale_advection, parameterized_eddy_advection,
> > parameterized_mesoscale_diffusion, parameterized_submesoscale_advection,
> > parameterized_dianeutral_mixing.
> >
> > a. Heat content
> >
> > We have two existing temperature_expressed_as_heat_content_names:
> > integral_of_sea_ice_temperature_wrt_depth_expressed_as_heat_content (J
> > m-2)
> > integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat_content
> > (J m-2).
> > Are the proposed heat quantity names also column integral quantities or do
> > they apply to a single grid cell? If the latter then I think we would need
> > to say 'expressed_as_heat_content_of_ocean_layer'.
I don't think the two existing names are necessarily integrals through the
whole depth. The definitions indicates they should have a depth axis to specify
the limits of integration.
The present proposals are for grid cells i.e. the tendencies are XYZT fields.
We could regard these as ocean layers, but I don't think we need to. I feel
it's fine to talk about the change in heat content, referring to a grid box.
It's an extensive quantity.
> > The units of the proposed names are W m-2 (i.e. J m-2 s-1). Perhaps it
> > would be clearer simply to say 'tendency_of_heat_content'. They are not
> > really temperature tendencies which would have units of K s-1. Some ocean
> > models in CMIP6 use potential temperature as their prognostic variable and
> > others use conservative temperature but the tendency of heat content is the
> > same quantity in both cases, no matter how it is calculated. I suggest
> > therefore that we don't need to distinguish between potential and
> > conservative temperature in these names. If it is important to state which
> > prognostic variable was used to calculate the heat content it would be
> > better to do so in the long_name or comment attributes.
> >
> > Bringing these two ideas together we would end up with names of the
> > pattern tendency_of_heat_content_of_ocean_layer[_due_to_PROCESS] (W m-2).
> > This has the advantage of halving the number of new heat_content names that
> > we would need to introduce and simplifying the syntax. What do you think?
> >
> >
> This is a useful proposal. I recall discussing this issue with Jonathan,
> as I believe our original proposal was to do just as you say. However,
> Jonathan, I believe, raised some concerns. I believe the concerns were
> basically aimed at reducing the chances for confusion from the modelers.
>
> In general, I am reticent to move forward with this suggestion, since it
> does not accord with the published OMIP paper
> <http://www.geosci-model-dev.net/9/3231/2016/gmd-9-3231-2016.html> and thus
> would add a good bit of confusion to the CMIP6 process.
Originally I preferred intensive quantities viz rates of change of temperature
and salinity, and in that case we definitely have to specify whether it is
potential or conservative. When we changed to extensive quantities, following
Steve's argument, we retained the distinction. I don't remember arguing that
this was important, but I might have! If we started again, I would agree with
Alison's suggestion, but I'm also cautious of changing it now.
As above, I don't think we need "ocean layer".
> > b. Salinity names
> >
> > As with the heat content names, are these column integrals or layer
> > quantities? (For now I will assume the latter).
> >
>
> These are full column integrals.
I don't think they are. They are XYZT fields. See Table L1 of Griffies et al
2016, 10.5194/gmd-9-3231-2016
> This is a useful proposal. I recall discussing this issue with Jonathan,
> as I believe our original proposal was to do just as you say. However,
> Jonathan, I believe, raised some concerns. Jonathan??
I don't remember whether I raised any concerns before. As above, I think it may
be too late to change now. I don't think we need _of_ocean_layer.
> > The possible values of PROCESS for these names are taken from the
> > following list: advection, parameterized_mesoscale_advection,
> > parameterized_eddy_advection, parameterized_mesoscale_diffusion,
> > parameterized_submesoscale_advection, parameterized_dianeutral_mixing.
> >
> > Firstly, I would say that we don't need 'parameterized' in any of the
> > names. We don't do this for other model parameterization schemes such as
> > clouds, convection or radiation, so I think it is safe to assume that all
> > sub-grid scale processes are parameterized without stating it explicitly.
> >
> >
> I am NOT happy dropping "parameterized". Here is a scenario that I wish to
> avoid. Namely, in the future, more models will be built with resolutions
> sufficient to resolve mesoscale eddies. So if we drop the "parameterized"
> portion of the name, it is possible (admittedly unlikely, but still
> possible) that a modeller would diagnose the mesoscale portion of the
> resolved flow field and submit it as the "mesoscale_advection"
> contribution. That is not the intent for these diagnostics. Instead, the
> intent is to diagnose the eddy parameterization contributions. If there
> are no parameterizations, then these fields should be zero or missing.
>
> "bolus" is an obsolete term. The oceanography community has thus moved
> forward with "eddy_advection" rather than "bolus_advection". Indeed, with
> a strict physical interpretation, "bolus" refers only to a small subset of
> what the oceanography community now refers to as "eddy_advection". So we
> decided to move forward by not propagating "bolus".
>
> Hence, although a bit clumsy and not fitting other precedents, I strongly
> recommend we keep the "parameterized" portion of the name.
I agree.
> > If they are the same, then we should either use
> > 'bolus_advection' in the proposed names or change the existing names to use
> > 'eddy_advection' to maintain consistency.
Yes, I think we should change bolus_advection to parametrized_eddy_advection in
existing names, using aliases for backward compatibility. There are some
"bolus" names where it's not a straight substitution:
bolus_eastward_sea_water_velocity:m s-1
bolus_northward_sea_water_velocity:m s-1
bolus_sea_water_x_velocity:m s-1
bolus_sea_water_y_velocity:m s-1
bolus_upward_sea_water_velocity:m s-1
ocean_tracer_bolus_biharmonic_diffusivity:m4 s-1
ocean_tracer_bolus_laplacian_diffusivity:m2 s-1
What should be do with these, Steve?
> > The proposed tendency definitions describe submesoscale_advection as
> > 'parameterized submesoscale eddy advective processes' and the heat
> > transport definitions describe mesoscale_advection as 'mesoscale
> > eddy-induced effects not included in the resolved model velocity field.'
> > Piecing this together, does this mean that 'mesoscale_advection' and
> > 'submesoscale_advection' are both contributions to total 'eddy_advection'?
> > In any case, if these are eddy advection processes I think it would make
> > more sense to label them as such, i.e. mesoscale_eddy|bolus_advection and
> > submesoscale_eddy|bolus advection.
> >
> Great suggestion. We should modify to read "mesoscale_eddy_advection" and
> "submesoscale_eddy_advection". Again, we should NOT promote the use of
> "bolus" any more.
Do you mean we should have due_to_parameterized_mesoscale_eddy_advection
instead of due_to_parameterized_mesoscale_advection and
due_to_parameterized_submesoscale_eddy_advection instead of
due_to_parameterized_submesoscale_advection? I agree we could do that. It's
longer but maybe clearer. We might need aliases already though.
I am happy with Steve's proposed text about eddies. Thank you, Steve.
Best wishes
Jonathan
Received on Fri May 19 2017 - 04:39:10 BST
