WRF
WRF copied to clipboard
wrf-model
Error in WRFv4.4.1 VEGPARM.TBL for NLCD with Noah LSM
Describe the bug Pull request https://github.com/wrf-model/WRF/pull/1733 added LCZ_n values to VEGPARM.TBL for the NLCD40 land use classification. According to the PR, the LCZ_n values were pulled from the MODIS assignments using the rationale that the NLCD40 is a blend of NLCD and MODIS. Testing for that update was presumably not performed with the Noah model, so the tests for the PR passed. However, when using the Noah LSM, the LCZ_n values under NLCD40 erroneously assign urban characteristics to non-urban land use categories 31-40; see L982-987 in phys/module_sf_noahdrv.F. With WRFv4.4.1 using NLCD40 and Noah LSM, this error in VEGPARM.TBL leads to systematic increases in mean monthly 2-m temperature of 1.5-2.0 deg C in the test configuration.
To Reproduce I found this problem by trying to upgrade WRF from v4.2.2 to v4.4.1. I ran seven 12-km, 31-year and one-year historical, reanalysis-driven test cases with WRF to track down the source of the error, including testing with interim versions of WRF between v4.2.2 and v4.4.1, as well as toggling options that were updated to default in the progressive releases of WRF. I eventually isolated the problem in VEGPARM.TBL.
Expected behavior I did not expect a systematic increase in mean monthly 2-m temperature across my domain by changing from WRFv4.2.2 to WRFv4.4.1. The issue was resolved by further updating VEGPARM.TBL to assign categories to the LCZ_n that exceed the maximum number of land use categories that we could consider. In my case, I tested with using "99", but I think the better route may be to increase to either "999" or "9999" to indicate a "missing value" or something you don't want to use.
Screenshots Can be provided upon request. I'll include them with the eventual PR to resolve this issue...unless NCAR staff wants to handle this with my input.
Attachments Can be provided upon request. I'll include them with the eventual PR to resolve this issue....unless NCAR staff wants to handle this with my input.
Additional context Examined comparisons of mean monthly 2-m temperature using 7 iterations with WRF before isolating this issue in VEGPARM.TBL. Issue can be resolved by changing LCZ_n associated with NLCD40 in VEGPARM.TBL to reflect a value that exceeds the maximum number of land use categories that would be expected so that non-urban land use categories are not inadvertently assigned as urban. As mentioned above, I tested using "99" for each of the LCZ_n, and the issue of the systematic increase in monthly mean 2-m temperature was resolved. As far as I could tell, the error is triggered with the combination of Noah and NLCD40 (with no urban model enabled) at lines 982-987 in phys/module_sf_noahdrv.F.
@tlspero Thanks for spotting the issue. If you can create a PR to address this issue, it will be greatly appreciated. Please follow instructions on this wiki page to proceed: https://github.com/wrf-model/WRF/wiki/Workflow-for-WRF-Code-Modification.
Looks like the solution provided above will impact the urban simulations if changing all LCZ_n to 99 in the table. In this case, when users activate urban model and LCZ capability, then it will not run correctly due to the unrecognized "99" for LCZ_n in the urban model code. @andreazonato Andrea, do you have any suggestion? (Andrea is the main LCZ developer implementing this capability in WRF v4.4).
I think that for NLCD the LCZ* should be defined in different ways. It should be done in this way:
LCZ_1=90 LCZ_2=90+1 and so on...
inside the VEGPARM.TBL section of NLCD. In this way, LCZs should not be present inside the domain.
Andrea
@cenlinhe and @andreazonato -- Yes, I agree. After thinking about this more yesterday, I decided that the implementation should values for each LCZ_n that are unique from each other and from the valid indices in the land use scheme. In this case, using LCZ_[1-11] set to 31-41 (as in WRFv4.4.1) interfered with actual categories in NLCD40.
If you want to have 11 LCZs that are supplemental to NLCD40, any indices that are greater than 40 would work. If you want to make this universal for all land use classifications, then you could simply choose any suite of indices that is larger than the maximum number of categories that you'd ever have.
I'm happy to work with you on either a solution that is specific to NLCD40 or using values that are universal for all land use classifications. Let me know how you want to proceed.
Maybe 90+ would be fine, but I worry about backward compatibility in the code if it relies on the current numbers matching the table. Imagine someone updating the code and keeping their old tables. At least an error detection could be added.
On Thu, Nov 10, 2022 at 11:26 AM Tanya Spero @.***> wrote:
@cenlinhe https://github.com/cenlinhe and @andreazonato https://github.com/andreazonato -- Yes, I agree. After thinking about this more yesterday, I decided that the implementation should values for each LCZ_n that are unique from each other and from the valid indices in the land use scheme. In this case, using LCZ_[1-11] set to 31-41 (as in WRFv4.4.1) interfered with actual categories in NCLD40.
If you want to have 11 LCZs that are supplemental to NCLD40, any indices that are greater than 40 would work. If you want to make this universal for all land use classifications, then you could simply choose any suite of indices that is larger than the maximum number of categories that you'd ever have.
I'm happy to work with you on either a solution that is specific to NLCD40 or using values that are universal for all land use classifications. Let me know how you want to proceed.
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/issues/1782#issuecomment-1310725535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77BMKL4O3L2N3QLG6STWHU47BANCNFSM6AAAAAAR3T4MEM . You are receiving this because you commented.Message ID: @.***>
@dudhia -- True. I guess it's a matter of how the developers want to proceed here. Do you prefer a universal set of LCZ_n that will work for all land use classification schemes in WRF, or would you like those numbers to be tailored for each land use scheme? If it's the former, then you will need to deviate from 31-41 because most of that range includes valid land use indices in NLCD40.
Should I expect @cenlinhe to weigh in here before I submit a PR?
Also...if we use a universal set of LCZ_n to supplement urban categories for all land use classifications, do they need to be in the VEGPARM.TBL?
I will discuss this with Andrea @andreazonato before we get back to this group here regarding which path we want to go. Thank you!
I favor using 90+ or something as long as we don't cause problems for previous users.
On Thu, Nov 10, 2022 at 12:08 PM Cenlin_He @.***> wrote:
I will discuss this with Andrea @andreazonato https://github.com/andreazonato before we get back to this group here regarding which path we want to go. Thank you!
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/issues/1782#issuecomment-1310771728, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77ANQUDUZN3DTEHWFKDWHVBZTANCNFSM6AAAAAAR3T4MEM . You are receiving this because you were mentioned.Message ID: @.***>
changing this table value will also affect the generation of global LCZ map that is going to be implemented into WPS.
Maybe we need a quick fix for V4.4.2 and a longer term change for V4.5 when the LCZ WPS input becomes available.
Andrea and I have discussed and decided to change the current LCZ_n type of 31-41 to 51-61 to avoid conflicting with existing land type data. I will make the PR for these changes. It is essentially just changing the LCZ values in three tables (MPTABLE.TBL for Noah-MP and LANDUSE.TBL and VEGPARM.TBL for Noah and CLM). Please let us know if you have any concerns.
Thank you, @cenlinhe. Do you plan to include the LCZ_n in VEGPARM.TBL for the other land use classifications (e.g., NLCD40) and make the appropriate accommodations throughout the WRF system?
Yes, the changes will be for existing WRF land use classifications (MODIS, USGS, NLCD) and land surface models (Noah, Noah-MP, CLM). These are the ones currently working with LCZ capability
One more question for you, @cenlinhe: if the LCZ_n are the same for all land use classifications, then why do we need the extra lines in the VEGPARM.TBL? Why not just have documentation that LCZ_n are supplemental urban categories that can be optionally assigned to land use indices 51-61? As it is implemented in WRFv4.4.1--and as you can probably gather from my initial proposed solution--it is misleading because it suggests that you can modify the assignments of LCZ_n and tailor them specifically for any land use classification system.
That said, I suggest that you consider removing the entries of LCZ_n from LANDUSE.TBL (and revert back to the WRFv4.2.2 LANDUSE.TBL without LCZ_n), if LCZ_n are identical for all land use classifications. Just my $0.02.
The reason to put LCZ_n in these parameter tables is because the LSMs need to read in these "LCZ_n" parameter to decide if a certain pixel is urban or not when the LCZ capability is activated (use_wudapt_lcz=1 in the namelist) and also some different treatments are done for different LCZ_n, which relies on the use of these specified LCZ_n values read from the tables. The LCZ code implementation was made to ensure enough flexibility so that LCZ_n can be easily changed in those tables which will not require any code changes in urban physics. However, to allow the LCZ to work, we still need the explicit variables "LCZ_n" to be specified. Also, there is an on-going effort to produce a global 100-m LCZ map for WPS implementation, which includes the LCZ_n category, so the LCZ_n values we decided here will affect the production of that product and its implementation in WPS. Luckily, that work is still in the testing stage so that we have the opportunity to modify the LCZ_n in tables right now.