WRF indicators

[j3r3m1]

To run WRF, the following urban characteristics should be calculated (according to Chen et al. 2022, Table 1):

• Mean building height: already calculated and rasterized ("BUILDING_HEIGHT")
• Distribution of building heights: has to be done since slightly different from the "roofAreaDistribution()" Process
• Area weighted mean building height: calculated (weightedAggregatedStatistics() Process) but not rasterized, should be rasterized using the same method as "BUILDING_HEIGHT")
• Standard deviation of building height: already calculated and rasterized ("BUILDING_HEIGHT")
• Plan area fraction: already calculated and rasterized ("BUILDING_FRACTION")
• Building surface to plan area ratio: simple sum of two already calculated and rasterized indicators ("BUILDING_FRACTION" and "FREE_EXTERNAL_FACADE_DENSITY") -> a new indicator (and IProcess) should be created "BUILDING_SURFACE_FRACTION"
• Frontal area index: the same as the "projectedFacadeAreaDistribution()" Process but when buildings are cutted by the cells... It seems this indicator is a fraction of the plan area and that it should also be divided by the height of the bin.

Additionnally, each pixel should be classified into one of the following three urban land use types:

• Low-density residential (urban area with pop density < 10 people/ha), high-density residential (urban area with pop density included between 10 and 100 people/ha), commercial (urban area with pop density > 100 people/ha)

Each pixel should also have the fraction of land and sea:

• fraction of sea/land: could be calculated using upperScaleAreaStatistics function ? #805

[j3r3m1]

• Low-density residential (urban area with pop density < 10 people/ha), high-density residential (urban area with pop density included between 10 and 100 people/ha), commercial (urban area with pop density > 100 people/ha)

Concerning this parameter, it is actually not feasible to use the 'urban_area' layer since the 'residential area' found in the OSM data of the French territories does not apply in any countries (for example nothing like that in Sweden). Thus there is to be a post-processing depending on where you want to process the indicator (and maybe this indicator is not 100% relevant). For Sweden, what we have done is considering the pixel as urban whenever we have at least a single building in it.

[j3r3m1]

For persons willing to use GeoClimate to produce the WRF spatial inputs, they should add the following indicators to the list of indicators to calculate at grid scale:

• Mean building height -> "BUILDING_HEIGHT"
• Distribution of building heights -> "BUILDING_HEIGHT_DIST"
• Area weighted mean building height -> "BUILDING_HEIGHT_WEIGHTED"
• Standard deviation of building height -> std is automatically calculated along with mean if you add "BUILDING_HEIGHT"
• Plan area fraction -> "BUILDING_FRACTION"
• Building surface to plan area ratio -> "BUILDING_SURFACE_DENSITY"
• Frontal area index -> "FRONTAL_AREA_INDEX"
• fraction of sea/land -> "SEA_LAND_FRACTION"

Note that the full methodology to creating the indicators is now described in the wiki

[ebocher]

Note that the full methodology to creating the indicators is now described in the wiki
do you have an url ?

[j3r3m1]

For Windows: https:/orbisgis/geoclimate/wiki/Creates-WRF-inputs-on-Windows
For Linux: https:/orbisgis/geoclimate/wiki/Creates-WRF-inputs-on-Linux

[andreazonato]

Little note: It is not necessary to assign Low-density residential, high-density residential or commercial , but LCZs can be used instead (LCZ1=51...LCZ10=60)

Andrea

[j3r3m1]

Discussions with Andrea and Alberto, the informations useful for WRF can be calculated at RSU scale.
The colorfull indicators should are the ones needed in WRF basic or multilayers:

We do not have to calculate them, just make sure that they can be postprocessed with all indicators we have

• LF_URB2D: "BUILDING_FRACTION" and "HIGH_VEGETATION_BUILDING_FRACTION" should be summed
• MH_URB2D: we calculate geometric mean height and average building height weighted by building area but not the basic average building height. @andreazonato is this indicator has to be added ?
• STDH_URB2D: Same as the previous, we calculate the standard deviation weighted by building area but not the basic standard deviation. @andreazonato is this indicator has to be added ?
• (EDIT: not needed) LF_URB2D: "PROJECTED_FACADE_AREA_DISTRIBUTION_Hx_y_Dw_z" which will have to be post-processed since you have to divide the indicator by the height of each height range. @andreazonato, two questions raised however:
  • Are the default values chosen for height interval and angle intervals fine ? Currently, the bottom level of each height range are [0, 10, 20, 30, 40, 50] and the degree range is 30°.
  • As for WRF you need as postprocessing to divide by the interval range how should we solve the fact that the last interval is a non-defined interval (>50 m) ? Do you want we calculate the maximum building height for each RSU ? Or extending the number of levels up to several hundred meters (having much bigger range for higher levels) ?
• HGT_URB2D: "AVG_HEIGHT_ROOF_AREA_WEIGHTED"
• LF_URB2D: simple sum of two already calculated indicators ("BUILDING_FRACTION" and "FREE_EXTERNAL_FACADE_DENSITY")
• HI_URB2D: from what I understand, it is different than the information needed in SURFEX. In SURFEX, we calculate a roof area considering the type of roof you may have (tilted, flat or vertical surfaces are considered) so the total area can be higher than the building fraction, thus leading to values higher than 1. @andreazonato is this what you need in WRF ? If this is not (and I think it is not), then we can use the "roofFractionDistributionExact" function which I think makes the job.

I think for both SURFEX and WRF, the number of buildings should also be added to this list as it might be useful for post-processing.

[andreazonato]

Hi @j3r3m1 . Finally I'm replying to you about it. Point by point:

LF_URB2D: "BUILDING_FRACTION" and "HIGH_VEGETATION_BUILDING_FRACTION" should be summed

Is HIGH_VEGETATION_BUILDING_FRACTION the vertical fraction of buildings (sum area of the facades/total grid cell area)?
If yes, yes, the sum is the lambda_b required by WRF. If it regards just the vegetation , I would not include it in the computation, since BEP+BEM would consider it as an artificial surface even for the energy budget, so I would not include it in the computation.

MH_URB2D: we calculate geometric mean height and average building height weighted by building area but not the basic average building height. @andreazonato is this indicator has to be added ?

It is not required by BEP+BEM, but required by the SLUCM (single layer urban model present in WRF). So yes, I guess it is required

STDH_URB2D: Same as the previous, we calculate the standard deviation weighted by building area but not the basic standard deviation. @andreazonato is this indicator has to be added ?

Same as previous

LF_URB2D: "PROJECTED_FACADE_AREA_DISTRIBUTION_Hx_y_Dw_z" which will have to be post-processed since you have to divide the indicator by the height of each height range. @andreazonato, two questions raised however:
Are the default values chosen for height interval and angle intervals fine ? Currently, the bottom level of each height range are [0, 10, 20, 30, 40, 50] and the degree range is 30°.
As for WRF you need as postprocessing to divide by the interval range how should we solve the fact that the last interval is a non-defined interval (>50 m) ? Do you want we calculate the maximum building height for each RSU ? Or extending the number of levels up to several hundred meters (having much bigger range for higher levels) ?

I guess here you are referring to the frontal area index. I'm not an expert on this (It is a parameter required by the SLUCM),
but I know it is not a vertical distribution, but instead a single value, each for every wind direction. In the document it is defined as " Those with 4 indices contain four wind directions (0°, 135°, 45°, 90°), which can be projected another 180°. ".
It is pretty confusing, but as far as I know, this parameter is not mandatory, so I would avoid to include this in the output.

HI_URB2D: from what I understand, it is different than the information needed in SURFEX. In SURFEX, we calculate a roof area considering the type of roof you may have (tilted, flat or vertical surfaces are considered) so the total area can be higher than the building fraction, thus leading to values higher than 1. @andreazonato is this what you need in WRF ? If this is not (and I think it is not), then we can use the "roofFractionDistributionExact" function which I think makes the job.

This value is basically the percentage (total sum of 100%) of buildings of a given height (in a vertical grid of dz=5 m).
Let's say that we have 4 buildings of 5m of height, 4 buildings of 10m height, 2 of 20 m. In total, 10 buildings in that grid cell.

So the variable will be, for that grid cell:

HI_URB2D(1)=40 !% of buildings of 5m height
HI_URB2D(2)=40 !% of buildings of 10m height
HI_URB2D(3)=0 !% of buildings of 15m height
HI_URB2D(2)=20 !% of buildings of 20m height

I think that the other thing that can be helpful as post processing, is a netcdf output of the variables, so one can easily implement it in the WPS (WRF Preprocessing System).

If you have further dubts, I'm here! And thanks for the effort you are putting on Geoclimate

[j3r3m1]

OK, thank you for your detailed answers.

Concerning frontal area index, isn't it needed for the drag coefficient calculation ?

I forgot to add something from your previous comment:

• LCZ are needed (LCZ1=51...LCZ10=60)

And according to Alberto answer to one of my email, a last indicator is needed:

• FRC_URB2D: which in our case will be the sum of road and building fraction.

[j3r3m1]

Concerning frontal area index, isn't it needed for the drag coefficient calculation ?

It seems only useful for the calculation of roughness lenght based on Macdonald (1990). As Andrea said it is only used by SLUCM which is not multilevel (but directional) while the multilevel model is not directional (use of the building height distribution only) so an option would be to only calculate the wall distribution performed for SURFEX-MesoNH and we might be able to postprocess this indicator if needed in the future...

[andreazonato]

Sorry for the late reply.

Yes, it is needed just for the roughness length of SLUCM. I think maintaining the calculations you do for SURFEX-MesoNH is a good solution to avoid overlaying of different similar parameters. An user could, in case, add information by himself

Thanks

Andrea

[j3r3m1]

OK, I think all needed WRF indicators will soon be calculable from the GeoClimate outputs (cf. #949). Here is a summarize of what postprocessing will be needed to have them.

• LF_URB2D: "BUILDING_FRACTION" + "HIGH_VEGETATION_BUILDING_FRACTION"
• MH_URB2D: "AVG_HEIGHT_ROOF"
• STDH_URB2D: "STD_HEIGHT_ROOF"
• HGT_URB2D: "AVG_HEIGHT_ROOF_AREA_WEIGHTED"
• Building surface to plan area ratio LF_URB2D: "BUILDING_FRACTION" + "FREE_EXTERNAL_FACADE_DENSITY"
• Frontal area index LF_URB2D: not needed yet but if needed an option would be to use the wall distribution ("PROJECTED_FACADE_AREA_DISTRIBUTION_Hx_y_Dw_z" with x and y being height and x and z being directions in °) and to postprocess it to reach the right indicator definition
• HI_URB2D: All indicators are like "ROOF_FRACTION_DISTRIBUTION_HX_Y" for X and Y being the lower and upper values of a given atmospheric layer and "ROOF_FRACTION_DISTRIBUTION_HX_INF" for the upper atmospheric layer
• LCZ: have to be converted to LCZ1=51...LCZ10=60. Rural LCZ are not needed.
• FRC_URB2D: "BUILDING_FRACTION" + "HIGH_VEGETATION_BUILDING_FRACTION" + "ROAD_FRACTION" + "HIGH_VEGETATION_ROAD_FRACTION" + "IMPERVIOUS_FRACTION" + "HIGH_VEGETATION_IMPERVIOUS_FRACTION"

[andreazonato]

Hi @j3r3m1
Yes, I m pretty sure your summary regards all the variables needed.
My only concern is about "HIGH VEGETATION BUILDING *". What do you mean by high vegetation?

Regarding the LCZs that are beside the LCZ60, they are actually vegetation land uses. And therefore, they are treated separately by WRF, so there is no need by Geoclimate to treat them.

Cheers!

[j3r3m1]

OK good concerning LCZ.

Concerning high_vegetation_building, no worries it is consistent with the definition you like (taking into account only building and not vegetation). The HIGH_VEGETATION_BUILDING_FRACTION is actually the fraction of surfaces which are covered by a buildings with trees above (either because they are planted on the roof, either because of lack of accuracy for building or trees or either because a tree has actually branches above a building). Thus summing "BUILDING_FRACTION" (which is building surfaces having no trees above) and "HIGH_VEGETATION_BUILDING_FRACTION" we have the total building fraction (covered or not by trees).

[andreazonato]

ok great, makes sense!

Thanks for this development. Let me know if you want me to do some testing =)