Potential bug for initializing urban fraction

[cenlinhe]

This is a known issue recently reported by Lingbo Xue (@xuelingbo) and Prof. Van Doan (@doan-van) from Univ of Tsukuba.

Currently, in the real.exe step (module_initialize_real.F), if a grid is urban type but FRC_URB2D in that grid is zero (e.g., outside US over urban regions; FRC_URB comes from NLCD in WPS and thus no data outside US), then the real.exe will assign 0.9 for the FRC_URB2D as a default initial value. (see code here: https://github.com/wrf-model/WRF/blob/develop/dyn_em/module_initialize_real.F#L3159-L3163).

However, this real.exe treatment prevents the urban model from reading in the FRC_URB values from URBPARM.TBL during the urban parameter initialization module for grids without FRC_URB data (now set to 0.9 by real.exe). See code here: https://github.com/wrf-model/WRF/blob/develop/phys/module_sf_urban.F#L2810-L2818.
In this case, the table value will not be effective since it is already replaced by the default 0.9 value from real.exe.

Potential solution/bug fix:
(1) commenting out the setting of 0.9 in module_initialize_real.F;
or
(2) add a if-statement to limit this 0.9 default setting to only places where NUDAPT (or NLCD) data is available.

[cenlinhe]

@barlage @tslin2 Could you please take a look when you have time?

[barlage]

@cenlinhe I guess the main question I have is: what do we want the code to be doing? Is there something beyond a quick fix that we should do? There are so many switches now for data sources, the logic is getting a little messy and confusing. I'm not sure what the motivation is for the default setting of 0.9, but that seems over prescriptive to me.

[cenlinhe]

@barlage I agree. At some point, we need to clean up things for urban part. I also agree that the default setting of 0.9 is unnecessary and probably we should remove it.

[cenlinhe]

Here is a history commit for this part of code added to WRF: 748beef

[tslin2]

0.9 is used as it is the default assumption in the model that high density residential urban type is used if urban type is not given, which is the same as the default table. However, if someone wants to change the table values and does not provide a spatial map, that would be the problem.

[tslin2]

Another related issue is the landcover. The landcover is different if comparing the no urban model (option 0) to the urban model (1, 2, or 3).

WRF/dyn_em/module_initialize_real.F

Line 3153 in b7f31dc

(grid%ivgtyp(i,j).NE.13 .AND. grid%ivgtyp(i,j).NE.24 .AND. grid%ivgtyp(i,j).NE.25 .AND. grid%ivgtyp(i,j).NE.26 .AND. grid%ivgtyp(i,j).LT.30)) grid%ivgtyp(i,j)=13

[cenlinhe]

@Yuqi-Ng
@chenghaow
Could you please take a look?

[tslin2]

Another related issue is the landcover. The landcover is different if comparing the no urban model (option 0) to the urban model (1, 2, or 3).

WRF/dyn_em/module_initialize_real.F

Line 3153 in b7f31dc

(grid%ivgtyp(i,j).NE.13 .AND. grid%ivgtyp(i,j).NE.24 .AND. grid%ivgtyp(i,j).NE.25 .AND. grid%ivgtyp(i,j).NE.26 .AND. grid%ivgtyp(i,j).LT.30)) grid%ivgtyp(i,j)=13

This also affects CGLC-MODIS-LCZ, some grids which are not urban in the land cover data become urban grids with land cover index 13 and then the LCZ urban types 5

[chenghaow]

This is a known issue for grid cells with no urban fraction data. 0.9 is apparently too high for most urban grid cells outside the U.S. In our previous simulations, we either assigned a moderate urban fraction (such as 0.5) or replaced the urban fraction input with data we derived from remote sensing data.

As for the land cover type discrepancies, we are working to fix this. Will create a pull request for this later.

[cenlinhe]

Sorry, I forgot to mention that this issue was originally brought up by Lingbo Xue (@xuelingbo) and Prof. Van Doan (@doan-van) from Univ of Tsukuba. They may provide more suggestions and comments. Also we would like to coordinate the group here for the bug fix to avoid duplicated work.
We will also make sure people contributing to identifying and helping to solve problems get their credits for this community contribution when the bug fix is officially released.

[xuelingbo]

I agree with @cenlinhe that assign 0.9 for the FRC_URB2D as a default initial value in the real.exe step shoulde be removed, to make the logic clearer:

1. if the user provides resonable FRC_URB2D, use that value directly, unresonable value will be corrected in read table step;
2. if the user does not provide a value for FRC_URB2D, the table will be read and the user can modify the value in the table to meet their needs.
   

   WRF/dyn_em/module_initialize_real.F

   Line 3161 in b7f31dc

   (grid%ivgtyp(i,j)==24 .OR. grid%ivgtyp(i,j)==25 .OR. grid%ivgtyp(i,j)==26 .OR. grid%ivgtyp(i,j)==13) ) grid%FRC_URB2D(i,j) = 0.9

Also for the land cover correction, what code should do is if FRC_URB2D>0.5 but land cover is not urban, then change land cover to urban. So,

1. if the user provides the FRC_URB2D, do land cover correction in real.exe step;
2. if the user does not provide a value for FRC_URB2D, the FRC_URB2D will be read from the table in sf_urban step based on the land cover. This ensures that there will be no cases where the urban fraction contradicts the land cover, and no correction will be required.
   

   WRF/dyn_em/module_initialize_real.F

   Line 3153 in b7f31dc

   (grid%ivgtyp(i,j).NE.13 .AND. grid%ivgtyp(i,j).NE.24 .AND. grid%ivgtyp(i,j).NE.25 .AND. grid%ivgtyp(i,j).NE.26 .AND. grid%ivgtyp(i,j).LT.30)) grid%ivgtyp(i,j)=13

So I think we can remove the whole if statement and add a land cover correction when user provide FRC_URB2D.