Different LU_INDEX between wrfinput and met_em files

[lpilz]

Describe the bug
When using USGS landuse data augmented with LCZ information by W2W, the LU_INDEX field in the wrfinput file is different from the one in the met_em file (cf. screenshots).

I think the reason for this is the following lines of code from 2018 (before LCZ were introduced):
https://github.com/wrf-model/WRF/blame/d66e442fccc04111067e29274c9f9eaccc3cef28/dyn_em/module_initialize_real.F#L3155-L3158

To Reproduce
Steps to reproduce the behavior:

1. Use compiler and version 'any, I use gcc+openmpi and v4.3.3'
2. Use namelist options 'use_wudapt_lcz=1, num_land_cat=41 and surface_input_source=3 (default)'
3. Output is 'cf. Screenshots'

Expected behavior
I would expect the LCZ urban information not to be overwritten in the LU_INDEX field of the wrfinput file and to be the same as in the met_em file.

Especially since the LU_INDEX information is used as the IVGTYP field in phys/module_sf_noahmpdrv.F and for determining urban type and morphology in phys/module_sf_urban.F. This urban type then, determined from IVGTYP is then used in phys/module_sf_bep.F to get the urban parameters.

Screenshots
wrfinput LU_INDEX field:

met_em LU_INDEX field:

[lpilz]

@cenlinhe @andreazonato Maybe you can help? :)

[cenlinhe]

This code mentioned by you: https://github.com/wrf-model/WRF/blame/d66e442fccc04111067e29274c9f9eaccc3cef28/dyn_em/module_initialize_real.F#L3155-L3158
indeed seems the cause of your issue. To fix this bug, please add:
" .AND. grid%ivgtyp(i,j).LT.30" to
"IF ( grid%FRC_URB2D(i,j) .GE. 0.5 .AND. &
grid%ivgtyp(i,j).NE.1 )"
to avoid replacing the LCZ categories.

Could you please do a test by using this fix to see if it works? If so, could you please submit a PR for this bug fix to the WRF GitHub? Thank you!

[lpilz]

Thanks, Cenlin! I checked it and it seems to work. Now the only difference between the met_em file and the wrfinput file is that some LU_INDEX 28 in the met_em are reclassified to 16 in the wrfinput. However, I think this is just a reclassification between water body types in USGS and it should (hopefully) be fine. I'll prepare a PR for the bug fix asap. :)

[lpilz]

However, what eludes me is why the check shouldn't read:

IF ( grid%FRC_URB2D(i,j) .GE. 0.5 .AND. & grid%ivgtyp(i,j).NE.1 .AND. grid%ivgtyp(i,j).ST.30)

Don't we only want to replace the tiles where the URBFRAC is >0.5 and which are not urban (i.e. ivgtyp!=1 and ivgtyp<30)? I mean it does work with >30 but I don't quite get why :D

[cenlinhe]

First, the ".ST." should be ".LT.", maybe this is a typo from your end?
Second, this is to correct the non-urban tiles with urban fraction>0.5 to be urban tiles. the "<30" is used to avoid doing this for LCZ classes (51~61). For USGS, the total # of land type classes is 27. Does this solve your confusion?

[lpilz]

Ah, sorry I always mix up that "LT" stands for "less than" and not "larger than" in fortran 😅 Thanks a lot :)