Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Subsoil Level not found in ungrib file

William.Hatheway

William.Hatheway

Active member
Subsoil level 0 in the GRIB2 file, was not found in the Vtable

The only thing changed is the intel compilers made a change in 2015.1.1

here are the dev notes. @islas do you see anything that would cause ungrib.exe to fail ?
www.intel.com

Intel® oneAPI DPC+/C+ Compiler Release Notes

This document summarizes new and changed product features and includes notes about features and problems for the Intel® oneAPI DPC+/C+ Compiler.
www.intel.com www.intel.com


@kwerner
forum.mmm.ucar.edu

NAM Vtable: Issue with subsoil level

Good day, When running ungrib.exe, I get the following error message: "Subsoil level 3 in the GRIB2 file, was not found in the Vtable". In the NAM grib file, I see that for soil temperature, there are five layers with the same discipline, category, parameter, and level code. Can that be...
forum.mmm.ucar.edu forum.mmm.ucar.edu
I saw this post from the past, but my metgrid shows 0 soil levels.

I've uploaded everything I think you might want to see to nextcloud file:
William.Hatheway.tar.xz
 
Last edited:
Any ideas
William.Hatheway said:
Subsoil level 0 in the GRIB2 file, was not found in the Vtable

The only thing changed is the intel compilers made a change in 2015.1.1

here are the dev notes. @islas do you see anything that would cause ungrib.exe to fail ?
www.intel.com

Intel® oneAPI DPC+/C+ Compiler Release Notes

This document summarizes new and changed product features and includes notes about features and problems for the Intel® oneAPI DPC+/C+ Compiler.
www.intel.com www.intel.com


@kwerner
forum.mmm.ucar.edu

NAM Vtable: Issue with subsoil level

Good day, When running ungrib.exe, I get the following error message: "Subsoil level 3 in the GRIB2 file, was not found in the Vtable". In the NAM grib file, I see that for soil temperature, there are five layers with the same discipline, category, parameter, and level code. Can that be...
forum.mmm.ucar.edu forum.mmm.ucar.edu
I saw this post from the past, but my metgrid shows 0 soil levels.

I've uploaded everything I think you might want to see to nextcloud file:
Willi
Click to expand...

Anyone have any ideas what is going on?
 
Hi,
I used the util/rd_intermediate.exe utility to look at the data in your intermediate files (FILE:*) and there is no soil moisture or soil temperature data in there. Did you look at the GFS input files to see if data for those variables are included? If not, try using the util/g2print.exe program to check. GFS data should have four levels for each.

If the files do include those variables, will you share the gfs input files and the Vtable you're using? Thanks.
 
kwerner said:
Hi,
I used the util/rd_intermediate.exe utility to look at the data in your intermediate files (FILE:*) and there is no soil moisture or soil temperature data in there. Did you look at the GFS input files to see if data for those variables is included? If not, try using the util/g2print.exe program to check. GFS data should have four levels for each.

If the files do include those variables, will you share the gfs input files and the Vtable you're using? Thanks.
Click to expand...
I will get that information for you here shortly after my weather model stops running (GNU compilers)
 
kwerner said:
Hi,
I used the util/rd_intermediate.exe utility to look at the data in your intermediate files (FILE:*) and there is no soil moisture or soil temperature data in there. Did you look at the GFS input files to see if data for those variables is included? If not, try using the util/g2print.exe program to check. GFS data should have four levels for each.

If the files do include those variables, will you share the gfs input files and the Vtable you're using? Thanks.
Click to expand...
William.Hatheway said:
@kwerner @islas

here are the files requested

Click to expand...
@kwerner @islas

Here's the output from the intel compilers using thoses commands as well as gnu using the same files and commands. The only variable changing is the compiler, intel vs gnu
 

Attachments

  • intel..zip
    12.4 KB · Views: 1
  • gnu..zip
    12.5 KB · Views: 1
Apologies for the delay. I tested this on our NCAR HPC, using your gfs input files, and I'm not having the issue you're having. You mentioned you are using Intel v15*? That compiler is nearly a decade old now, so it's possible there is some sort of issue with the older compiler. For reference, we use Intel 2024.2.1.
 
kwerner said:
Apologies for the delay. I tested this on our NCAR HPC, using your gfs input files, and I'm not having the issue you're having. You mentioned you are using Intel v15*? That compiler is nearly a decade old now, so it's possible there is some sort of issue with the older compiler. For reference, we use Intel 2024.2.1.
Click to expand...
sorry missedtype intel oneapi 2025.1.0
 
kwerner said:
Apologies for the delay. I tested this on our NCAR HPC, using your gfs input files, and I'm not having the issue you're having. You mentioned you are using Intel v15*? That compiler is nearly a decade old now, so it's possible there is some sort of issue with the older compiler. For reference, we use Intel 2024.2.1.
Click to expand...
my thoughts is it is something to do with how the compiler reads the ungrib commands?
 
@William.Hatheway In WPS at ungrib/src/rd_grib2.F please try the following (76-78 are just line numbers to provide context):
Code: 
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
 
islas said:
@William.Hatheway In WPS at ungrib/src/rd_grib2.F please try the following (76-78 are just line numbers to provide context):
Code: 
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
Click to expand...
with the configure_new build do I need to modify any other file locations?

I made the changes and here is the output from the rd_intemediate file:
 

Attachments

  • rd_intermidate.log
    74.4 KB · Views: 1
Here's the ungrib log file

I noticed also with the configure_new the ungrib.exe log file is now named logfile.log whereas it used to be ungrib.log. Was that intentional ?
 

Attachments

  • logfile.log
    58.6 KB · Views: 0
islas said:
@William.Hatheway Did you rerun ungrib with the changes? The issue is not with the rd_intermediate executable. The logfile.log change is unintentional and will need a fix
Click to expand...
I've rerun the ungrib with the changes you asked me to do. Here's the log file is attached. These were the commands I executed:
Code: 
ln -sf ungrib/Variable_Tables/Vtable.GFS ./Vtable
./link_grib.csh $WRFROOT/GFS/
./ungrib.exe

The source data is here:


I built WPS using these commands
Code: 
    source /opt/intel/oneapi/setvars.sh --force
    cd "${WRF_FOLDER}"
    git clone https://github.com/wrf-model/WPS.git
    
    #If statment for changing folder name
    if [ -d ""${WRF_FOLDER}"/WPS" ]; then
        mv -f "${WRF_FOLDER}"/WPS "${WRF_FOLDER}"/WPS-${WPS_VERSION}
    fi
        
    cd "${WRF_FOLDER}"/WPS-${WPS_VERSION}
    
     ./configure_new -x -p "Intel oneAPI compilers" -- -DCMAKE_Fortran_COMPILER=ifx -DMPI_Fortran_COMPILER=mpiifx -DMPI_C_COMPILER=mpiicx -DWRF_ROOT=${WRF_ROOT} -DBUILD_EXTERNALS=OFF -DZLIB_ROOT=${ZLIB_ROOT} -DPNG_ROOT=${PNG_ROOT} -DJasper_ROOT=${Jasper_ROOT} -DUSE_MPI=ON 2>&1 | tee wps.configure.log
     ./compile_new -d -j $CPU_QUARTER_EVEN 2>&1 | tee wps.compile.log
    
     rm -rf     "${WRF_FOLDER}"/WPS-${WPS_VERSION}/_build

# 1) Symlink the three main binaries into the top‐level as *.exe
for exe in ungrib metgrid geogrid; do
  ln -sf "${WRF_FOLDER}/WPS-${WPS_VERSION}/install/bin/$exe" \
         "${WRF_FOLDER}/WPS-${WPS_VERSION}/$exe.exe"
done

# 2) Symlink all util/* programs as *.exe
for util in avg_tsfc calc_ecmwf_p g1print g2print height_ukmo int2nc mod_levs rd_intermediate; do
  ln -sf "${WRF_FOLDER}/WPS-${WPS_VERSION}/install/bin/$util" \
         "${WRF_FOLDER}/WPS-${WPS_VERSION}/util/$util.exe"
done

The environment is:


Code: 
export LD_LIBRARY_PATH=/home/workhorse/WRF_Intel/Libs/NETCDF/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/home/workhorse/WRF_Intel/Libs/grib2/lib:$LD_LIBRARY_PATH
export PATH=/home/workhorse/WRF_Intel/Libs/grib2/lib:$PATH
 

Attachments

  • logfile.log
    58.6 KB · Views: 1
  • ungrib.log
    53.3 KB · Views: 1
  • g2print.log
    67.2 KB · Views: 1
Last edited:
As far as I can tell, the real -> integer patch fixes the missing subsoil levels. I cannot reproduce the errors with the patch using the data and configs you provided.
 
islas said:
As far as I can tell, the real -> integer patch fixes the missing subsoil levels. I cannot reproduce the errors with the patch using the data and configs you provided.
Click to expand...
What can I provide to help reproduce the errors?

I will try the patch again
 
You must log in or register to reply here.
Top