You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the Annual Meeting in Bergen, Tomas mentioned the possibility of saving the internal values of the individual tiles of the LSM, which are averaged to produce the value of a given variable on the gridcell. In the context of urban modelling, this allows to isolate the variables of the urban part of the gridcells, e.g. to compute the UHI more accurately. This is not included in the I4C data request, but might be considered in the updates of the FPS-URB-RCC data request if models are able to write these values out.
Here I describe only how this can be coded in a CF compliant way. These variables are already considered in CMIP6. They have the suffix Lut (i.e.: by land use type). For example, this is how tasLut looks in the CMOR table and here is an example of a file coded in this way (3 MB) from ESGF.
This makes use of the second and more flexible way of applying statistics to portions of cells, as described in CF1.11, section 7.3.3. Thank you, @cofinoa, for noticing this. It seems that, with this approach, there is no need to introduce new area types into CF, but they can be user defined in a variable with the standard_name area_type which enumerates the area types where the statistic is sequentially applied along a new dimension.
This can be another option to code the variables for the different urban canopy model components (roof, wall, road, ...) discussed in #6 in a single variable (e.g. tasUrb) with an additional dimension along the different components. In this respect, note that in CMIP6 there are also variables for a single land use type, such as tasmaxCrops.
The text was updated successfully, but these errors were encountered:
During the Annual Meeting in Bergen, Tomas mentioned the possibility of saving the internal values of the individual tiles of the LSM, which are averaged to produce the value of a given variable on the gridcell. In the context of urban modelling, this allows to isolate the variables of the urban part of the gridcells, e.g. to compute the UHI more accurately. This is not included in the I4C data request, but might be considered in the updates of the FPS-URB-RCC data request if models are able to write these values out.
Here I describe only how this can be coded in a CF compliant way. These variables are already considered in CMIP6. They have the suffix
Lut
(i.e.: by land use type). For example, this is howtasLut
looks in the CMOR table and here is an example of a file coded in this way (3 MB) from ESGF.This makes use of the second and more flexible way of applying statistics to portions of cells, as described in CF1.11, section 7.3.3. Thank you, @cofinoa, for noticing this. It seems that, with this approach, there is no need to introduce new area types into CF, but they can be user defined in a variable with the standard_name
area_type
which enumerates the area types where the statistic is sequentially applied along a new dimension.This can be another option to code the variables for the different urban canopy model components (roof, wall, road, ...) discussed in #6 in a single variable (e.g.
tasUrb
) with an additional dimension along the different components. In this respect, note that in CMIP6 there are also variables for a single land use type, such as tasmaxCrops.The text was updated successfully, but these errors were encountered: