-
Notifications
You must be signed in to change notification settings - Fork 708
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
Comments
@cenlinhe @andreazonato Maybe you can help? :) |
This code mentioned by you: https://github.com/wrf-model/WRF/blame/d66e442fccc04111067e29274c9f9eaccc3cef28/dyn_em/module_initialize_real.F#L3155-L3158 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! |
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. :) |
However, what eludes me is why the check shouldn't read:
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 |
First, the ".ST." should be ".LT.", maybe this is a typo from your end? |
Ah, sorry I always mix up that "LT" stands for "less than" and not "larger than" in fortran 😅 Thanks a lot :) |
…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.
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:
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 theIVGTYP
field inphys/module_sf_noahmpdrv.F
and for determining urban type and morphology inphys/module_sf_urban.F
. This urban type then, determined from IVGTYP is then used inphys/module_sf_bep.F
to get the urban parameters.Screenshots
wrfinput LU_INDEX field:
met_em LU_INDEX field:
The text was updated successfully, but these errors were encountered: