[CF-metadata] new standard_names

From: Jonathan Gregory <j.m.gregory>
Date: Fri, 11 Nov 2005 07:37:09 +0000

Dear Burkhardt

We have agreed these so far:

  water_potential_evaporation_amount kg m-2
  runoff_amount kg m-2
  sea_ice_temperature K
  surface_geopotential m2 s-2
  surface_specific_humidity 1
  mass_fraction_of_rain_in_air 1
  mass_fraction_of_snow_in_air 1
  mass_fraction_of_graupel_in_air 1
  convective_cloud_base_altitude m
  convective_cloud_top_altitude m
  atmosphere_surface_drag_coefficient_of_momentum 1
  atmosphere_surface_drag_coefficient_of_heat 1
  lwe_thickness_of_frozen_water_content_of_soil_layer m
  coriolis_parameter s-1
  atmosphere_enthalpy_content J m-2
  atmosphere_potential_energy_content J m-2
  upwelling_shortwave_flux_in_air W m-2
  downwelling_shortwave_flux_in_air W m-2
  upwelling_longwave_flux_in_air W m-2
  downwelling_longwave_flux_in_air W m-2
  tendency_of_air_temperature_due_to_radiative_heating K s-1
  convective_cloud_area_fraction_in_atmosphere_layer 1
  magnitude_of_surface_downward_stress
  duration_of_sunshine s
  soil_porosity (1)
  soil_type string
  geostrophic_eastward_wind (m s-1)
  geostrophic_northward_wind (m s-1)
  surface_downwelling_photosynthetic_radiative_flux_in_air (W m-2)
  mass_fraction_of_precipitation_in_air
  tendency_of_atmosphere_kinetic_energy_content_due_to_advection (W m-2)
  tendency_of_atmosphere_potential_energy_content_due_to_advection (W m-2)
  tendency_of_atmosphere_enthalpy_content_due_to_advection (W m-2)
  model_level_number_at_convective_cloud_base (1)
  model_level_number_at_convective_cloud_top (1)
  model_level_number_at_top_of_atmosphere_boundary_layer (1)
  altitude_at_top_of_dry_convection m
  atmosphere_momentum_diffusivity (m2 s-1)
  atmosphere_heat_diffusivity (m2 s-1)
  atmosphere_convective_mass_flux (kg m-2 s-1)
  equivalent_pressure_of_atmosphere_ozone_content (Pa)
  wind_speed_of_gust m s-1

In answer to other points:

The unit in the standard_name table is "canonical" - any dimensionally
equivalent unit is acceptable.

> soil_moisture_volume_fraction_at_field_capacity (1)
I think I'd prefer a more explicit construction analogous to mass_fraction_of
X_in_Y and volume_mixing_ratio_of_X_in_Y, thus
  volume_fraction_of_water_in_soil_at_field_capacity 1
  volume_fraction_of_water_in_soil_at_wilting_point 1
OK?

> land_use 1
> Examples for land use are "urban, evergreen forests, cool rain forest,
> wooded wet swamp" etc.
Given this range of meanings, perhaps land_cover would be a better name for
it? It could be unintuitive to call natural vegetation a "land use", I guess.

> Plotting programs may have problems with string variables. Is there a
> possibility to map the string array to another that holds just
> numbers, i.e. a fixed number for each string (for instance 1 = urbane,
> 2 = evergreen forest, ...)?
That would be against the CF principle of making the file self-describing. But
you could include an auxiliary coordinate variable of your own definition to
supply such numbers, with the same dimension as the land_cover coord variable.

As a further step, we could draw up a list of permitted values for land_cover
and soil_type, as we have done for region, and as is also needed for plant
functional types. As Roy says in the lake thread, we should look around to see
if such standardised lists already exist.

> sub_scale_mass_fraction_of_cloud_liquid_water_in_air 1
> sub_scale_mass_fraction_of_cloud_ice_in_air 1
> In some models grid scale clouds (i.e. for cloud cover = 1 in a grid
> box) are treated differently from sub grid clouds (i.e. for cloud
> cover < 1).
I see. I haven't come across this. Could you distinguish them by adding a
coordinate variable of cloud_area_fraction?

> snow_fall_limit_altitude m
> This is the altitude where the wet bulb temperature > 1.3 Celsius
> (definition by Meteo Swiss). Thus snow does not melt instantaneously,
> when it passes the 0 Celsius altitude. Therefore
> snow_level_limit_altitude is different from freezing_level_altitude.
This could be described with a standard_name of altitude and a single-valued
coordinate variable of wet_bulb_temperature.

> difference_of_air_pressure_from_reference (Pa)
> There is no standard reference pressure. The reference pressure
> profile is different amongst non-hydrostatic atmosphere models. Even
> for the same model the users may define it seperately. The difference
> of pressure from reference profile is often used as prognostic
> variable in non-hydrostatic models instead of the total pressure. I
> guess because of numeric precision reasons.
OK. Would it be all right to call it
  difference_of_air_pressure_from_model_reference (Pa)
to make clear that it's a model quantity? Specifying the reference could be
done with a standard_name parameter, for which we still haven't defined the
exact convention.

> air_pressure_at_ozone_maximum Pa
> If I would use the existing standard name
> "mole_fraction_of_ozone_in_air" and "cell_methods", how does
> cell_methods look like?
I would put cell_methods="mole_fraction_of_ozone_in_air: maximum". This is
permitted by the last paragraph of CF 7.3; it stretches the current convention
slightly, but it seems to make sense to me. What do you think?

> toa_net_downward_longwave_flux W m-2
> I am struggling a bit with the definition TOA. I assume this
> is the "real" TOA not the model top? Our model is not at p=0 but at
> z=25km. That means the downward longwave radiation at the top of our
> model is not zero. I guess I should use the general names for
> upwelling and downwelling fluxes (these are "OK as proposed" above)
> and add a height dimension that contains just one number (25 in this
> case). Actually, it would be analogue to definitions of 2metre
> temperature and 10metre wind. What do you think?
Yes, I think that would be the most informative way to do it. Alternatively
we could define a name net_downward_longwave_flux_at_top_of_atmosphere_model -
we already have net_downward_radiative_flux_at_top_of_atmosphere_model.

> I thought every quantity
> should be given a standard name. I will use just the long name.
It is not mandatory to use a standard_name. The advantage of standard_names
is that they facilitate data exchange. But for quantities whose use is only
local, especially if they are rather application-specific, it may not be
appropriate to define a standard name.

However, it may be more convenient always to use the standard_name attribute,
and not have to look at the long_name as well. Possibly we could define some
way to indicate that a standard_name was not in fact standard! We should
discuss this kind of issue as a part of a more general discussion about how
to expand the standard_name table, as soon as the manager of standard names
is in post so that some more effort can be put into it.

Best wishes

Jonathan
Received on Fri Nov 11 2005 - 00:37:09 GMT