Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different LU_INDEX between wrfinput and met_em files #2152

Open
lpilz opened this issue Jan 8, 2025 · 6 comments
Open

Different LU_INDEX between wrfinput and met_em files #2152

lpilz opened this issue Jan 8, 2025 · 6 comments
Assignees

Comments

@lpilz
Copy link
Contributor

lpilz commented Jan 8, 2025

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:
wrfinput LU_INDEX field
met_em LU_INDEX field:
met_em LU_INDEX field

@lpilz
Copy link
Contributor Author

lpilz commented Jan 8, 2025

@cenlinhe @andreazonato Maybe you can help? :)

@cenlinhe
Copy link
Contributor

cenlinhe commented Jan 8, 2025

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
Copy link
Contributor Author

lpilz commented Jan 8, 2025

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
Copy link
Contributor Author

lpilz commented Jan 8, 2025

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
Copy link
Contributor

cenlinhe commented Jan 8, 2025

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
Copy link
Contributor Author

lpilz commented Jan 8, 2025

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

weiwangncar pushed a commit that referenced this issue Jan 17, 2025
…SGS urban category. (#2153)

TYPE: bug fix

KEYWORDS: LCZ, USGS

SOURCE: Lukas Pilz (Heidelberg University)

DESCRIPTION OF CHANGES:
Problem:
As shown in #2152, for USGS data the wrfinput LU_INDEX field has major differences to the met_em LU_INDEX field. Cells in LU_INDEX which have LCZ categories (>30) were overwritten with the default USGS urban category (1) where FRC_URB2D > 0.5.

Solution:
Add a check similar to the MODIS case above.

ISSUE:
Fixes #2152 

LIST OF MODIFIED FILES: 
M    dyn_em/module_initialize_real.F

TESTS CONDUCTED: 
1. Did local tests, the only differences between wrfinput and met_em which remain are changing LU_INDEX 28 to 16, which is a water body redesignation as to my knowledge.
2. Jenkins tests have passed.

RELEASE NOTE: Bug fix for wrfinput where LCZ urban cells in LU_INDEX were overwritten with default USGS urban category.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants