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.

[LluisFB]

I modified the code in the fork of the WRF code that we are using in the CORDEX FPS URB RCC. I changed the line with the following code (sorry I do not know how to make it as nice as you did in your posts), in dyn_em/module_initialize_real.F line #3124 (might not be the same in the actual WRF repository)
From the original line:

              IF ( grid%FRC_URB2D(i,j) == 0. ) THEN
                 IF ( (MMINLU == 'NLCD40' .OR. MMINLU == 'MODIFIED_IGBP_MODIS_NOAH') .AND. &

To changes

              IF ( grid%FRC_URB2D(i,j) == 0. ) THEN
                 IF ( (MMINLU == 'NLCD40') .AND. &

After doing that, I performed a 2-day simulation at 4 km resolution over the metropolitan area of Buenos Aires. At this resolution, I have only 4 LCZ types. Comparing before/after for each type I got the following results:

Individual evolution of 10-m tempertaure in the 76 grid points with LCZ=56 within AMBA (top line), grid point average (line), +/- standard deviation (darker shadow), mininum-maximum values (fainter shadow) for the 76 grid points (bottom line). First column original values, modification values (middle column) and differences (right column)

Same figure, but for 10-m westward wind speed

You can find more analyses in this pdf

[weiwangncar]

@cenlinhe @dudhia Should this be a bug fix in 4.7?