Subsoil Level not found in ungrib file

[William.Hatheway]

@William.Hatheway In WPS at ungrib/src/rd_grib2.F please try the following (76-78 are just line numbers to provide context):

76      integer , dimension(maxlvl) :: level_array
77      integer :: glevel1, glevel2 !< HERE change from real to integer
78      logical :: first = .true.

I believe this comes down to a misuse of types and the nuances of comparing of different precisions without explicit known narrowing to do a comparison (the actual error really did look like 10.000001 != 10)

I've confirmed this works for me using Intel 2025.1.1, and if it also works for you I will go ahead and make a WPS pull request

I figured out the issue, I modified the file after configuring and compiling when I needed to modify it before it. That seems to fix the problem as you said.

 

[William.Hatheway]

I figured out the issue, I modified the file after configuring and compiling when I needed to modify it before it. That seems to fix the problem as you said.

@islas

Has this patch been pushed to the official github?

 

[islas]

Please follow the progress of this PR for further updates:

Change glevel 1 and 2 to ints to prevent floating point equality checks by islas · Pull Request #275 · wrf-model/WPS

All comparisons to glevel1 and glevel2 are against integer values, relying on implicit conversion during the check if done somewhat correctly. When implicit conversion is not done, the floating poi...

github.com

 

[William.Hatheway]

Please follow the progress of this PR for further updates:

Change glevel 1 and 2 to ints to prevent floating point equality checks by islas · Pull Request #275 · wrf-model/WPS

All comparisons to glevel1 and glevel2 are against integer values, relying on implicit conversion during the check if done somewhat correctly. When implicit conversion is not done, the floating poi...

github.com

Thanks

 

[bluewaves]

@William.Hatheway In WPS at ungrib/src/rd_grib2.F please try the following (76-78 are just line numbers to provide context):

76      integer , dimension(maxlvl) :: level_array
77      integer :: glevel1, glevel2 !< HERE change from real to integer
78      logical :: first = .true.

I believe this comes down to a misuse of types and the nuances of comparing of different precisions without explicit known narrowing to do a comparison (the actual error really did look like 10.000001 != 10)

I've confirmed this works for me using Intel 2025.1.1, and if it also works for you I will go ahead and make a WPS pull request

I am using Intel oneapi 2025.2 and I also got the same errors.
This led to NUM_METGRID_SOIL_LEVELS = 0 in met_em files. Your fix solved the problem. Thank you.

 

[Nathan Kelly]

I am also using Intel and trying to initialize WRF with HRRR and had the exact same issue. Thank you for fixing my problem with this thread!

 

[William.Hatheway]

@islas @weiwangncar @kkeene44

I can also confirm this issue is persistent in AMD AOCC compilers

 

[islas]

Do you mean that the original issue is observable with the AOCC compilers, and the fix works for that or that even with the fix the issue is still persistent on the AOCC compilers?

 

[William.Hatheway]

Do you mean that the original issue is observable with the AOCC compilers, and the fix works for that or that even with the fix the issue is still persistent on the AOCC compilers?

The issue is observable with AOCC compilers if the fix is not present. When the fix is applied the AOCC compileed WPS programs work and read grib files.