Adding surface layer variables

[o2kenobi]

Global Hydrology Resource Center (GHRC)
Author: Yuling Wu

In searching for proper standard names (SD) for our AMSR products, we carefully sift through the CF's SD list, have found proper names for most our products and have proposed a couple of new additions to the CF SD list. One parameter left out of our request cf-convention/vocabularies#22 is the temperature at 2m. It is a physically quantity of air temperature. However, it has a special importance in meteorology, along with relative humidity at 2m, wind (U and V) at 10m). What separate them from the same physical quantities at other vertical levels are: 1) they are standard measurements at standard surface stations (per WMO); 2) models following the Monin-Obukhov surface layer similarity theory for the surface layer simulation use these quantities and also have them in the output. M-O similarity theory is a very common practice; 3) both NOAA and ECMWF have included these variables in the reanalysis datasets and designated grib types (level type) for them ;4) they are separated from the 3D variables in a model as they are not on the 3D grid.

Surface layer is a very important component of the atmosphere in meteorology, as it is where the energy exchange (heat flux, moisture flux, etc) takes place that drives the dynamics and thermodynamics of the atmospheric systems. And these surface variables provide a measure for the surface layer status and the exchange.

So we propose to add following parameters to the Standard Names list:

-Term: air_temperature_at_2m
-Description: Air temperature measured at 2 meter height.
-Canonical Units: K

-Term: relative_humidity_at_2m
-Description: Relative humidity measured at 2 meter height.
-Canonical Units: %

-Term: wind_speed_at_10m
-Description: Wind speed measured at 10 meter height.
-Canonical Units: m s-1

-Term: u_component_wind_at_10m
-Description: U component wind measured at 10 meter height.
-Canonical Units: m s-1

-Term: v_component_wind_at_10m
-Description: V component wind measured at 10 meter height.
-Canonical Units: m s-1

[taylor13]

I would not like to introduce these new names because, we can already store the variables as we have done historically. In support of CMIP over more than two decades, we have stored these variables with the accepted standard names and with a scalar coordinate variable providing the height information. We have never received a complaint about this practice. It has flexibility that has made it possible for models that produce output at a slightly different height (e.g. 1.5 m, rather than 2 m) specify useful surface information. I think we should continue to rely on the standard name as identifying what physical quantity is being measured (air_temperture, relative_humidity, etc.) and rely on coordinates to determine where the quantity is being measured.

[JonathanGregory]

I agree with Karl.

[sethmcg]

I also agree. This would be a significant break in backwards compatibility for a very large number of data products.

[ngalbraith]

I also agree with Karl, however I was struck by the descriptions, e.g. 'Wind speed measured at 10 meter height'.

Working with observational data, I'd be very interested to know if there's a standard way to indicate that a variable represents wind speed that was measured at 2 m and then modified to represent the 10 m wind.

I realize this may be outside the CF realm, but I'm doing some work with the newer Coare algorithm for surface fluxes, and there are some issues like this. Using a long name doesn't provide any machine readability. Without meaning to derail (or prolong) this github issue, any ideas on how to correctly represent this would be greatly appreciated.

[ninsbl]

Hi, I am new to the CF standard and came across this issue when I was looking for suitable standard names for my data in the latest standard table, bt could not find one. I have data from temperature sensors from three places: on the earth surface, at 30cm and 200cm.

While I agree with @taylor13, that using the high information is likely the best way to describe the quality of the air_tempature data at 30cm and 200cm, I am actually missing a landsurface_temperature or skin_temperature variable for the temperature measured on the ground. The air_temperature definition, explicitly excludes the surface / skin, it says:
"Air temperature is the bulk temperature of the air, not the surface (skin) temperature." So, it does not feel right to use air_temperature as a variable name here....

But I could not find skin_temperature or land_surface_temperature as a variable (although the latter is frequently used in remote sensing)....

So, in essence, I would also like to see surface layer variables too...

[davidhassell]

Hello @ninsbl,

There was a good discussion on skin and surface temperatures over land and sea back in 2013 (unfortunately the link to the CF mailing list archive is down at the moment). The result of that was the surface_temperature standard name defined below, and that cell methods should be used to indicate if the temperature is restricted to being at the interface of the atmosphere and a particular surface type (such as land):

surface_temperature
alias: surface_temperature_where_land
alias: surface_temperature_where_open_sea
alias: surface_temperature_where_snow
The surface called "surface" means the lower boundary of the atmosphere. The surface temperature is the temperature at the interface, not the bulk temperature of the medium above or below. Unless indicated in the cell_methods attribute, a quantity is assumed to apply to the whole area of each horizontal grid box. Previously, the qualifier where_type was used to specify that the quantity applies only to the part of the grid box of the named type. Names containing the where_type qualifier are deprecated and newly created data should use the cell_methods attribute to indicate the horizontal area to which the quantity applies.

Thanks,
David

[taylor13]

To be sure, in CF an alias is a standard_name that might have been used in the past, but is now deprecated. So as David says, the standard_name you should use is surface_temperature, and you should include the cell_methods attribute, which in the simplest case might be set to cell_methods="area: mean where land".

[ninsbl]

Thanks, @davidhassell and @taylor13 for your very helpful replys!

So, my usecase is covered then by the latest standard. I somehow must have ended up in an older version of the standard table (like 60 or so). Thanks again!

[ngalbraith]

Can this issue be closed now? We've agreed that the proposed new standard names are not needed. Thank you - Nan

[larsbarring]

As Nan writes, there is agreement not to add the suggested standard names. And no additional comments or arguments in favour have been added in about two years. Hence I am closing this issue.