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: [email protected] Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
