[CF-metadata] new named fields for ocean

From: Karl Taylor <taylor13>
Date: Fri, 09 Jan 2009 17:23:58 -0800

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.
Received on Fri Jan 09 2009 - 18:23:58 GMT