CF compliance of FPS-URB-RCC variables

[jesusff]

From a discussion in Mattermost:

@ClaasTeichmann wrote:
Lars, Pia and I just discussed a bit the model output and its CMORization. We were wandering if the urban specific variables follow already the cf-convention, or better: is there somebody who takes care that this is done? It will be important, when we want to publish in ESGF or elsewhere.

@jesusff wrote:
Good points. AFAIK nobody is taking care of the CF compliance of the urban variables. We should enrol Peter and start working on this. On a fast look, the standard names are not in CF and it seems we'll need to ask new area types for inclusion in CF. We are discussing the impervious areas (FPS-URB-RCC/CORDEX-CORE-WG#21) but, among the urban variables, there are surface_temperature and air_temperature where roof/pavement/greenspaces/bluespaces defined with dedicated standard names (e.g. roof_surface_temperature), which is discouraged in CF and won't be accepted for inclusion. I guess this will lead us to, at least, CF-1.12

@ClaasTeichmann wrote:
Concerning the CF compliance issue, we can talk to Peter and possibly invite him here to chat with us.

@jesusff wrote:
As the timeline for the FPS is less pressing, we could also update our variable list to make it more compliant with CF standards, and then propose it to the FPS. We could open an issue to discuss all potential problems we see

This is the issue 😉
We can collect here the compliance problems we see. @larsbuntemeyer, did you find some particular problem?

[larsbuntemeyer]

@jesusff Thanks for collecting the discussion. My main concern would only be the standard names of URB-RCC variables that are not CF compliant (as you pointed out). I can create cmor tables from the csv tables in this repo, they provide all neccessary meta data, and i think it is fine for the FPS. For ESGF, having non CF compliant standard names might be an issue in the future...

[larsbuntemeyer]

I was actually thinking about implementing the standard names test in WCRP-CORDEX/data-request-table#37 to catch these kind of thing when new data requests come up. So URB-RCC would be an example that would fail this test...

[jesusff]

Thank you, @larsbuntemeyer. That would be great to have. And the CMOR tables for these CSVs would be really helpful for I4C and the FPS

[jesusff]

There is this old "discussion" that never really started, which is partially related to this issue: cf-convention/discuss#36

See also cf-convention/vocabularies#55

[jesusff]

OK, I made a first proposal of some changes to make the new variables more CF compliant, although some new definitions would be required. Namely:

• New standard name: upward_heat_flux_into_air_due_to_anthropogenic_urban_activities
• New area types:
  • pavement
  • roof
  • urban_green_space
  • urban_blue_space
  • urban_canyon

I'm not sure the last one can be considered a "surface", or an area type. We might need a dedicated standard name for it. I assume that the tsXXX refer to surface (skin) temperatures, i.e. the temperatures at the interface, not the temperatures of the roof/pavement/...

I proposed to replace anthroheat by hfas, which follows the building rules of similar variables, such as hfls or hfss. Assuming here that this will be a near-surface variable (e.g. not having heat fluxes at different levels).

I'm not sure of the meaning of tsskin and what would be the difference with respect to the standard ts.

We definitely need here some input from urban experts and discuss this with the FPS leads. Will contact them via e-mail, as I think only @GLangendijk is on github.

[jesusff]

Regarding the standard name for anthroheat/hfas there is:

surface_upward_heat_flux_due_to_anthropogenic_energy_consumption [W m-2]
The surface called "surface" means the lower boundary of the atmosphere. "Upward" indicates a vector component which is positive when directed upward (negative downward). The vertical heat flux in air is the sum of all heat fluxes i.e. radiative, latent and sensible. In accordance with common usage in geophysical disciplines, "flux" implies per unit area, called "flux density" in physics. The specification of a physical process by the phrase "due_to_" process means that the quantity named is a single term in a sum of terms which together compose the general quantity named by omitting the phrase. "Anthropogenic" means influenced, caused, or created by human activity. The heat flux due to anthropogenic energy consumption results from non-renewable human primary energy consumption, including energy use by vehicles, commercial and residential buildings, industry, and power plants. Primary energy refers to energy in natural resources, fossil and non-fossil, before conversion into other forms, such as electricity.

which I think describes exactly what we mean. We would just need to confirm that this is a surface flux and not e.g. multi-level.

[jesusff]

To move forward, here is a specific proposal for the description of the new area types (for reference, the current list is here):

  <entry id="builtup_impervious">
    <description>
      Built-up impervious surfaces are mainly composed of artificial materials 
      such as gravel, glass, asphalt, and metals. These surfaces are mainly found within
      urban areas and prevent or decelerate water infiltration.
    </description>
  </entry>

  <entry id="pavement">
    <description>
      Pavement areas comprise the hard, flat surfaces that form walkways, roads, 
      and other ground-level urban areas. Pavement areas are built-up impervious
      surface areas.
    </description>
  </entry>

  <entry id="roof">
    <description>
      Roof areas comprise the uppermost surfaces of buildings, regardless of
      their material and shape. Roofs are built-up impervious surface areas.
    </description>
  </entry>

  <entry id="urban_canyon">
    <description>
      In an urban area, the urban canyon areas comprise the ground-level space between
      buildings. These areas are affected by the surrounding buildings, which 
      impact the wind flow, sunlight penetration, temperature regulation, etc.
    </description>
  </entry>

  <entry id="urban_blue_space">
    <description>
      A blue space within an urban area comprises all water surfaces, either
      natural (e.g. ponds, lakes, rivers, sea waterfronts) or artificial
      (e.g. canals, fountains, pools).
    </description>
  </entry>

  <entry id="urban_green_space">
    <description>
      A green space within an urban area comprises all vegetated areas, such as
      parks or gardens. Unlike non-urban vegetated areas, urban green spaces are
      subject to the effect of the surrounding urban environment, e.g. shadows and
      radiation trapping by the buildings.
    </description>
  </entry>

I wrote it in a detailed way, in order to spark discussion. I'm no expert, so this needs careful revision. We also need to be careful with the wording (is, might be, mainly, ...). For example, with these definitions, green roofs would not be green spaces (not affected by building shadows) nor roofs (not impervious). If it makes sense, definitions could be relaxed so green roof areas could be areas where urban_green_space and roof

[jesusff]

Back to the surface_upward_heat_flux_due_to_anthropogenic_energy_consumption standard name. It is only used by variable fahLut in CMIP6, where it is thought to be provided by land use type (Lut). This variable is not available in ESGF from any model.

[jesusff]

The proposal above is copied in this Google doc to ease the refinement process. Please, comment and/or suggest changes there.

[jesusff]

Some insights from M. Lipson received via e-mail:

I agree with your defined areas and believe they align with urban climate community vocabulary, and also account for the varying ways that urban models represent urban components. I do have some suggestions to make the descriptions more explicit to avoid ambiguity.

1. I have seen disagreement between (and within) groups about an urban “impervious” definition, with some groups including buildings/roofs, and some excluding those areas (focusing only on what you have defined as “pavement”). Likewise, different groups have different meanings for “builtup”, some define it to be the whole “urban area”, some only the “urban structures”, i.e. building/roof areas. So, if you intend (as I believe you do) that builtup_impervious should include both roofs and pavements, then being explicit about this in the description would help.
2. Many urban areas (particularly in arid areas) have large areas of bare soil. These surfaces are not impervious, but also not “vegetation”. I believe the important concept is that these areas do not limit infiltration or evaporation, so I personally would place these within the “urban_green_space” area. If you agree, then this should be made explicit in the description.
3. There are varying ways that models represent “urban canyons”, with some models including only impervious pavements, while others include lawns, street trees, bare soil and blue spaces. To avoid ambiguity your canyon definition should be explicit about what is included in the canyon area (I believe pavements, green and blue spaces, to align with the variety of real world urban spaces, and with what is represented in various models).
4. Including “gravel” in the “impervious” area might cause confusion, as gravel is semi-pervious.
5. You are proposing sub-areas within the existing “urban” area type, and some sub-sub groups. I agree including sub-areas is important, however, it is not clear which subgroups consist of larger area types. The existing “sea_ice” and its subgroups could be used as examples to build on. For example, the “sea_ice” description is explicit that the subgroups sum to the larger group. Also the subgroups of the “sea_ice” type also start with “sea_ice_xxxx”. You could use this format with “urban_xxxx” area definitions, then all urban related areas appear together on the area list.
6. In your descriptions you sometimes use “surfaces” as synonymous with “area”, I’d suggest only using “areas” (as this is a CF area description).

Considering the above, my suggestions follow below [they are in 5b69f26], in which I have used your terms but with some extra clarifications. Thank you for the opportunity to comment. Please feel free to adapt or reject my suggestions as you see fit.