"Fortran runtime error: Bad value during integer read" when running wrf.exe

[alexjt]

I am trying to run a simple WRF test on two different machines and am trying to figure out why one was successful whereas another was not.

I am running the same test on both machines and am able to get all the way to wrf.exe on both. However, on the unsuccessful machine I get the following error in my rsl.error.0000 file:

###UNSUCCESSFUL rsl.error.0000

Timing for Writing wrfout_d01_2036-09-17_00:00:00 for domain 1: 24.97511 elapsed seconds
At line 777 of file module_date_time.f90
Fortran runtime error: Bad value during integer read

Error termination. Backtrace:
#0 0x14e742b8d171 in ???
#1 0x14e742b8dd19 in ???
#2 0x14e742b8e521 in ???
#3 0x14e742d93706 in ???
#4 0x14e742d97adc in ???
#5 0x14e742d98ca4 in ???
#6 0xf06daf in ???
#7 0xfb9102 in ???
#8 0x10453ea in ???
#9 0x1049f0b in ???
#10 0x468739 in ???
#11 0x407431 in ???
#12 0x406a1c in ???
#13 0x14e741dcc7e4 in ???
#14 0x406a5d in ???
#15 0xffffffffffffffff in ???

It is unclear to me if this means the wrfout file write finished or not. In my successful case, this is what the rsl.error.0000 file displays at the same place:

###SUCCESSFUL rsl.error.0000

Timing for Writing wrfout_d01_2036-09-17_00:00:00 for domain 1: 0.69404 elapsed seconds
Timing for processing lateral boundary for domain 1: 1.77285 elapsed seconds

While I have seen a few posts on the forum regarding the error "At line 777 of file module_date_time.f90 | Fortran runtime error: Bad value during integer read", they have not been helpful for me with this current issue. Any suggestions for solving this issue are appreciated.

 

[kwerner]

Hi,
Apologies for the long delay in response while our team tended to time-sensitive obligations. Thank you for your patience.

I see that you are using a very old version of WRF (v3.9.1.1), which is no longer supported. It's likely the two different machines have differing environments, library versions, compiler/versions, and those can all cause differences in simulations. Some compilers are triggered by specific errors, while others may move past them. Can you test this with the latest version of WRF (v4.6.1) and see if you're still getting the same error?

 

[alexjt]

Thank you for the reply. I have since found a solution to this specific issue, although I am unclear as to why the solution works.

This test (referred to above as UNSUCCESSFUL) was run on a cloud computing system, whereas the test referred to as SUCCESSFUL was run on a government-maintained HPE Cray system.

The source of the error on the cloud computing system was that real.exe was creating unreadable dates in wrfbdy_d01. This issue was confusing because rsl.error.0000 stated SUCCESS COMPLETE REAL_EM INIT, so I figured it was successful and I could move on to wrf.exe. The issue was that Times in wrfbdy_d01 had the following values:

Times =
 "\000\000\000\000\000\000\000\005\000\000\017\214\000\000\000\000\001\n",
 "\302",
 "2036-09-17_06:00:00",
 "2036-09-17_12:00:00",
 "2036-09-17_18:00:00" ;
}

The first value is what caused the error during wrf.exe. For some reason, the other dates were created successfully. This error arose from running real.exe in the following way:

sbatch runreal.slurm

runreal.slurm:

#!/bin/sh
#SBATCH [user-specific info]
#SBATCH -N 1
srun -n 36 ./real.exe >& real.log

However, when running real.exe on the head node via a different method, all dates were created successfully and wrf.exe was able to run.

./runreal.local

runreal.local:

#!/bin/sh
mpirun -n 36 ./real.exe >& real.log

 

[kwerner]

That's interesting, and I'm glad you were able to find a workaround. Thanks for explaining the solution that worked for you!