Potential bug for initializing urban fraction

[cenlinhe]

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