WRF-urban BEP: whether the module_sf_bep.F code has an error in calculating street width (ws)

[Liuzh223]

Describe the bug
When I used the W2W tool to generate the lp_urb and lb_urb in the wrfinput file. In module_sf_bep.F, when calculating ws and bs at line 1051, I think there is something wrong with the formula for ws. The calculation code is
ws(id)=2. * hgt_urb * lp_urb * ((frc_urb/lp_urb)-1.)/(lb_urb-lp_urb)
,but the formula works when frc_urb=1. Otherwise it will make the calculated ws slightly smaller, resulting in a slightly larger H/W.

To Reproduce
Steps to reproduce the behavior:

1. Use compiler and version 'WRFV4.4'
2. Use namelist options 'sf_urban_physics = 2'

Expected behavior
A clear and concise description of what you expected to happen.
I'm not sure if there are new changes to ws and bs later on, if not, the line of code needs to be changed to ws(id)=2.hgt_urblp_urb*((1/lp_urb)-1.)/(lb_urb-lp_urb) to get the correct ws value.

Screenshots

[weiwangncar]

@cenlinhe Can you take a look at this? Thanks!

[cenlinhe]

I think the BEP street width formulation is correct. This equation was originally designed to work with the NUDAPT urban parameter dataset, where (I believe) the lp_urb is defined as building plan area density in a sense of total grid/pixel area and that is why it needs to use lp_urb/frc_urb as an adjustment.

Also note that the equation you mentioned will be activated when you have the input data for lp_urb and lb_urb (e.g., from NUDAPT or your own generated ones from W2W). In other cases, it will directly read from the urban parameter table.

[Liuzh223]

Thank you very much for your reply!

In my previous issue, the python-based W2W tool considered lp_urb to be the building plan area density relative to impervious surfaces (FRC _URB2D), based on this I think the WRF code is wrong. The formulas are as follows.

1. lp_urb = bs/(bs+ws)
2. lb_urb = (2hgt_urb+bs)/(bs+ws)

The references are：
Zonato, A., Martilli, A., Di Sabatino, S., Zardi, D., & Giovannini, L. (2020). Evaluating the performance of a novel WUDAPT averaging technique to define urban morphology with mesoscale models. Urban Climate, 31, 100584. https://doi.org/10.1016/j.uclim.2020.100584

Demuzere, M., Argüeso, D., Zonato, A. and Kittner, J. (2022). W2W: A Python package that injects WUDAPT's Local Climate Zone information in WRF. Journal of Open Source Software, 7(76), 4432, DOI: [10.21105/joss.04432]

If lp_urb is defined as building plan area density in a sense of total grid/pixel area, the WRF code is correct only if the formulas for lp_urb and lb_urb are as follows.

3. lp_urb = (frc_urb2d * bs)/(bs+ws)
4. lb_urb = (frc_urb2d * (2hgt_urb+bs))/(bs+ws)

Bringing the above equation into the WRF code gives the correct bs and ws.
So far, i'm very confused about how to calculate lp_urb and lb_urb, because the python-based W2W tool calculates lp_urb and lb_urb in contradiction to WRF's calculations under my knowledge. I have searched for some NUDAPT papers but still can't find any formula about calculating lp_urb and lb_urb, could you provide me with the formula that you have used for calculating them?

[cenlinhe]

@Liuzh223 Thank you for the detailed info and reference! I was looking at the NUDAPT documentation in WRF (https://ral.ucar.edu/sites/default/files/public/product-tool/NUDAPT_44_Documentation.pdf), and it states that "The building width is a function of the plan area fraction, the building surface to plan area ratio, and the mean building height and the
street width is calculated based on the same parameters as well as the urban fraction."
Your equation 3 and 4 shown above actually gives the current WRF BEP code for bs and ws.

I did not find a specific reference showing the NUDAPT equations. If in your W2W tool, the equation does not have frc_urb, you could revise the BEP code to make it consistent with your W2W tool. Honestly, I cannot find the history of the BEP code change in terms of how this frc_urb came into the equation.

@andreazonato Do you have any thoughts on this?

[Liuzh223]

@cenlinhe Thank you very much for the detailed explanation.

I will multiply the lp_urb and lb_urb obtained from W2W calculations with the frc_urb to match the WRF code.
@andreazonato Would you have any suggestions for such a modification?

[andreazonato]

Hello everyone!

@Liuzh223 , thank you for pointing this out.

This is actually more than a simple calculation issue.
In fact, depends on the user to define the correct WS!

I mean: is the fraction of vegetation within the streets or not? If yes, you should multiply for the urban fraction, if not, you should keep the values as they are.

For this reason, I'm developing a W2W within WRF that does not depend on lambdas, but just on BW and SW divided or not by FRC_URB2D.

Hope I explained the issue

Andrea

[Liuzh223]

@andreazonato
Thank you for your kind reply!

I must admit that I am still a bit confused. It seems that the W2W tool generates the geo.em.d0X.nc file directly for WRF, according to the instructions in the W2W documentation. As I understand it, the urban parameters generated by W2W should match the WRF code, and this should not depend on how the user defines WS. Therefore, I don't quite understand your statement that "In fact, it depends on whether the user has defined the correct WS!"

Currently I have a situation where the vegetation in urban areas is kept consistent with WRF, and the lp_urb is relative to impervious surfaces. In this case, would you recommend modifying the code?

Thank you once again for your time and assistance!