Potential error with SLUCM when using nested domain.

[KennyPhan]

Describe the bug
I am running a one way nested domain (max_dom = 2,) using WRF Version 4.6.0 for the Midwest region using the traditional 3 urban categories for SLUCM. The model crashed immediately after trying to process domain 2 and getting an Fortran runtime error.

I believe that this error is caused by an incorrect processing/calculations of UTYPE and FRC_URB2D for domain 2. I looked at the wrfout files and found that domain 2’s UTYPE and FRC_URB2D values were completely different than what is expected and processed incorrectly compared to domain 1.

To Reproduce

Steps to reproduce the behavior:

1. Use WRFV4.6.0
2. Use my Urban 3 classes data in WPS.
3. Follow the Namelist.wps and namelist.input I attached below.

Data: ERA-5 and my 3 Urban classes
Note: I did not use the 2011 FRC_URB2D and URBPARM optional data.
GEOGRID.TBL Addition

name=LANDUSEF
priority=2
dest_type=categorical
z_dim_name=land_cat
interp_option = default:nearest_neighbor
rel_path = default:urban3_51/

Expected behavior
Since I did not provide the FRC_URB2D during WPS, REAL.exe created the FRC_URB2D field and mapped the LU_INDEX 13 (urban class for MODIFIED_IGBP_MODIS_NOAH) as 0.9 and the rest as 0 which is expected (module_initialize_real.F) and worked for both domain 1 and 2. I verified the number of cells and location.

During WRF for domain 1, UTYPE would assigned based on the LU_INDEX 51,52,53 to 1,2,3 and 0 for the non-urban LU_INDEX. Then WRF would read the URBPARM.TBL to assign the FRC_URB2D based on the UTYPE 1,2, or 3. Based on the URBPARM.TBL UTYPE 1 = 0.5, UTYPE 2 = 0.9, and UTYPE 3 = 0.95.

Domain 2 should do the same calculations of assigning UTYPE 1,2,3 based on the LU_INDEX 51,52,53. Read the URBPARM.TBL and assign the FRC_URB2D.

Actual behavior
For domain 1 it works as intended, I see the correct assignment of UTYPE 0,1,2,3 and FRC_URB2D 0,0.5,0.9,0.95 based on the LU_INDEX (13,51,52,53).

For domain 2 it is completely different than expected. The UTYPE seems to be random because I saw many non-urban LU_INDEX (not 13,51,52,53) were assigned to UTYPE 1,2, or 3, when they should be 0. Even the locations with LU_INDEX 51,52,53 were not assigned correctly. Then the FRC_URB2D was different because it had 2 very small negative values. The FRC_URB2D seemed to assign the values 0.5,0.9,0.95 to the cells with the wrong UTYPE 1,2,3 then interpolated the values because it has many unique values. I am very confused.

Screenshots
I used Python to examine my wrfout files.

Small Negative Values

Attachments
I attached my namelist.wps, namelist.input, rsl.out, and my 3 Urban Categories (urban3_51) + index file inside the Reproduce Zipped file.
Reproduce.zip

Additional context

• I ran the same simulations with just 1 domain, and it ran perfectly fine.
• I also ran the simulations with the provided 2011 FRC_URB2D in WPS and the same behavior happened. Where domain 2’s UTYPE is wrong and the FRC_URB2D has even more cells with negative values.
• I tried version 4.4.2 when the traditional urban classes were first changed from 31,32,33 to 51,52,53 and got the same error.
• My urban data and namelist should be correct and I do not think they would cause the issue I am seeing. However I could be wrong since I am a new user of WRF.
• If you need additional information please let me know.

[dudhia]

One test would be to make this modification in Registry.EM_COMMON to stop it interpolating FRC_URB2D to the nest.
state real FRC_URB2D ij misc 1 - i012rd=(interp_fcnm)u=(copy_fcnm) "FRC_URB2D" "URBAN FRACTION" "dimensionless"
to
state real FRC_URB2D ij misc 1 - i012r "FRC_URB2D" "URBAN FRACTION" "dimensionless"

[KennyPhan]

One test would be to make this modification in Registry.EM_COMMON to stop it interpolating FRC_URB2D to the nest. state real FRC_URB2D ij misc 1 - i012rd=(interp_fcnm)u=(copy_fcnm) "FRC_URB2D" "URBAN FRACTION" "dimensionless" to state real FRC_URB2D ij misc 1 - i012r "FRC_URB2D" "URBAN FRACTION" "dimensionless"

I clean -a, configured, and recompiled with your suggest changes. It worked, I now see in Python and ncview that the FRC_URB2D for the second domain is only 0, 0.5, 0.9, 0.95 (No negatives) and the occurrences matches matches the urban LU_INDEX correctly.

The other remaining issue is the UTYPE_URB still shows the wrong occurrences. It might be an interpolation issues? I see in the registry it is set to
state integer UTYPE_URB2D ij misc 1 - rd=(interp_fcni)u=(copy_fcni) "UTYPE_URB" "URBAN TYPE" "dimensionless"

[KennyPhan]

Update:

I modified my Registry.EM_COMMON to stop FRC_URB2D and UTYPE_URB2D interpolating to the nest.

---

state real FRC_URB2D ij misc 1 - i012rd=(interp_fcnm)u=(copy_fcnm) "FRC_URB2D" "URBAN FRACTION" "dimensionless"
to
state real FRC_URB2D ij misc 1 - i012rh "FRC_URB2D" "URBAN FRACTION" "dimensionless"

---

and

---

state integer UTYPE_URB2D ij misc 1 - rd=(interp_fcni)u=(copy_fcni) "UTYPE_URB" "URBAN TYPE" "dimensionless"
to
state integer UTYPE_URB2D ij misc 1 - rh "UTYPE_URB" "URBAN TYPE" "dimensionless"

---

With these change Domain 2 now has the expected number and assignment of UTYPE_URB2D and FRC_URB2D values for the urban LU_INDEX (13,51,52,53). WRF no longer give me the Fortran Runtime error.

This make sense to me because UTYPE_URB2D and FRC_URB2D are derived from the Urban LU_INDEX (13,51,52,53). The Urban LU_INDEX were already interpolated for my domain 2 during geogrid.exe. By stopping WRF from interpolating UTYPE and FRC_URB2D to the nest domain, it prevent the reclassification of those values. This allowed WRF to directly assign UTYPE and FRC_URB2D based on LU_INDEX, like it did in domain 1.

Does my interpretation of what is happening seem right to you?

Additional Notes
These two Registry changes also work fine you provide FRC_URB2D during geogrid.exe.

Geogrid.exe will interpolate your FRC_URB2D (some non urban LU_INDEX will have FRC_URB2D values) to your domains. When you run WRF it will maintain all the FRC_URB2D values that you calculated in Geogrid only for the urban LU_INDEX and assign 0 to all the non urban LU-INDEX from my testing.

[dudhia]

Sounds good and the LSM team here can review this. If you know how to do a github pull request you could do that starting with the latest release.

…

On Thu, Mar 27, 2025 at 10:42 PM KennyPhan ***@***.***> wrote: *Update:* I modified my Registry.EM_COMMON to stop FRC_URB2D and UTYPE_URB2D interpolating to the nest. ------------------------------ state real FRC_URB2D ij misc 1 - i012rd=(interp_fcnm)u=(copy_fcnm) "FRC_URB2D" "URBAN FRACTION" "dimensionless" to state real FRC_URB2D ij misc 1 - i012rh "FRC_URB2D" "URBAN FRACTION" "dimensionless" ------------------------------ and ------------------------------ state integer UTYPE_URB2D ij misc 1 - rd=(interp_fcni)u=(copy_fcni) "UTYPE_URB" "URBAN TYPE" "dimensionless" to state integer UTYPE_URB2D ij misc 1 - rh "UTYPE_URB" "URBAN TYPE" "dimensionless" ------------------------------ With these change Domain 2 now has the expected number and assignment of UTYPE_URB2D and FRC_URB2D values for the urban LU_INDEX (13,51,52,53). WRF no longer give me the Fortran Runtime error. This make sense to me because UTYPE_URB2D and FRC_URB2D are derived from the Urban LU_INDEX (13,51,52,53). The Urban LU_INDEX were already interpolated for my domain 2 during geogrid.exe. By stopping WRF from interpolating UTYPE and FRC_URB2D to the nest domain, it prevent the reclassification of those values. This allowed WRF to directly assign UTYPE and FRC_URB2D based on LU_INDEX, like it did in domain 1. *Does my interpretation of what is happening seem right to you?* *Additional Notes* These two Registry changes also work well you provide FRC_URB2D during geogrid.exe. Geogrid.exe will interpolate your FRC_URB2D (some non urban LU_INDEX will has FRC_URB2D values) to your domains. When you run WRF it will maintain all the FRC_URB2D values that you calculated in Geogrid only for the urban LU_INDEX and assign 0 to all the non urban LU-INDEX from my testing. — Reply to this email directly, view it on GitHub <#2187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77DMBAKPBE3K5Q322OT2WTHM7AVCNFSM6AAAAABZ5XB542VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRQGE3DCMJXGI> . You are receiving this because you commented.Message ID: ***@***.***> [image: KennyPhan]*KennyPhan* left a comment (wrf-model/WRF#2187) <#2187 (comment)> *Update:* I modified my Registry.EM_COMMON to stop FRC_URB2D and UTYPE_URB2D interpolating to the nest. ------------------------------ state real FRC_URB2D ij misc 1 - i012rd=(interp_fcnm)u=(copy_fcnm) "FRC_URB2D" "URBAN FRACTION" "dimensionless" to state real FRC_URB2D ij misc 1 - i012rh "FRC_URB2D" "URBAN FRACTION" "dimensionless" ------------------------------ and ------------------------------ state integer UTYPE_URB2D ij misc 1 - rd=(interp_fcni)u=(copy_fcni) "UTYPE_URB" "URBAN TYPE" "dimensionless" to state integer UTYPE_URB2D ij misc 1 - rh "UTYPE_URB" "URBAN TYPE" "dimensionless" ------------------------------ With these change Domain 2 now has the expected number and assignment of UTYPE_URB2D and FRC_URB2D values for the urban LU_INDEX (13,51,52,53). WRF no longer give me the Fortran Runtime error. This make sense to me because UTYPE_URB2D and FRC_URB2D are derived from the Urban LU_INDEX (13,51,52,53). The Urban LU_INDEX were already interpolated for my domain 2 during geogrid.exe. By stopping WRF from interpolating UTYPE and FRC_URB2D to the nest domain, it prevent the reclassification of those values. This allowed WRF to directly assign UTYPE and FRC_URB2D based on LU_INDEX, like it did in domain 1. *Does my interpretation of what is happening seem right to you?* *Additional Notes* These two Registry changes also work well you provide FRC_URB2D during geogrid.exe. Geogrid.exe will interpolate your FRC_URB2D (some non urban LU_INDEX will has FRC_URB2D values) to your domains. When you run WRF it will maintain all the FRC_URB2D values that you calculated in Geogrid only for the urban LU_INDEX and assign 0 to all the non urban LU-INDEX from my testing. — Reply to this email directly, view it on GitHub <#2187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77DMBAKPBE3K5Q322OT2WTHM7AVCNFSM6AAAAABZ5XB542VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRQGE3DCMJXGI> . You are receiving this because you commented.Message ID: ***@***.***>

[dudhia]

Were you not reading in the urban arrays for domain 2? I am not sure why that doesn't override the interpolated urban arrays.

[KennyPhan]

Were you not reading in the urban arrays for domain 2? I am not sure why that doesn't override the interpolated urban arrays.

I am a little confused by your question. But I think yes, I was reading in the urban arrays for domain 2. My met_em_d02 files show the same LU_INDEX with the same number of occurrences in my wrfout file, so it seemed to read it. But WRF did not seem to process it in the calculation of UTYPE and FRC_URB2D. (Assign UTYPE to each cell based on the LU_INDEX ( 0 for non-urban and 1,2,3 for urban). Then the UTYPE would be used to assign the urban fraction value based on the LANDUSE.TBL).

WRF might be ignoring my domain 2 information, and interpolating domain 1's information to fill in domain 2.

Do you happen to know what interpolation methods are available in the registry? Do you know if nearest neighbor is available? I tried to look online but I had no luck.

I was thinking about changing the interpolation method in the registry to nearest neighbor to test if it would produce the correct results of FRC_URB2D and UTYPE because my LU_INDEX was created using nearest neighbor in WPS. In the registry FRC_URB2D and UTYPE seem to use different interpolation methods and I cannot tell what they are.

FRC_URB2D ij misc 1 - i012rd=(interp_fcnm)u=(copy_fcnm)
UTYPE_URB2D ij misc 1 - rd=(interp_fcni)u=(copy_fcni)

[cenlinhe]

@tslin2

[tslin2]

@tslin2

@KennyPhan can you provide the attached zipped file again? I am not able to extract the namelist.

Also, what are the source of your land cover data?

[KennyPhan]

@tslin2

That is strange I was able to download and unzip the file fine with winrar. I will try again.
namelist.zip
urban3_51.zip

I am using the default modis_landuse_20class_30s_with_lakes and my urban3_51.

Urban3_51 is urban land use data for the 3 traditional urban categories. This was created by downloading NLCD 2023 and reclassing the non-urban land use categories to 0 and Developed, Open Space (21) and Developed, Low Intensity (22) to 51, Developed, Medium Intensity (23) to 52, Developed, High Intensity (24) to 53.
Since I am using WRFV-4.6.0 I had to reclass the traditional urban categories to 51,52,53 instead of the old 31, 32, 33. I also resampled the data to 60m x 60m to reduce the file size so I can share the file and speed up geogrid.
I added my urban category data to the GEOGRID.TBL.

name=LANDUSEF
priority=2
dest_type=categorical
z_dim_name=land_cat
interp_option = default:nearest_neighbor
rel_path = default:urban3_51/

[KennyPhan]

@tslin2
Are you still having issues opening the files I attached in the previous comment?

@tslin2

That is strange I was able to download and unzip the file fine with winrar. I will try again. namelist.zip urban3_51.zip

I am using the default modis_landuse_20class_30s_with_lakes and my urban3_51.

Urban3_51 is urban land use data for the 3 traditional urban categories. This was created by downloading NLCD 2023 and reclassing the non-urban land use categories to 0 and Developed, Open Space (21) and Developed, Low Intensity (22) to 51, Developed, Medium Intensity (23) to 52, Developed, High Intensity (24) to 53. Since I am using WRFV-4.6.0 I had to reclass the traditional urban categories to 51,52,53 instead of the old 31, 32, 33. I also resampled the data to 60m x 60m to reduce the file size so I can share the file and speed up geogrid. I added my urban category data to the GEOGRID.TBL.

name=LANDUSEF priority=2 dest_type=categorical z_dim_name=land_cat interp_option = default:nearest_neighbor rel_path = default:urban3_51/