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

real.exe does not produce input files for d02 and d03


New member

I am a beginner in WRF who is setting up a nested run using WRF 4.4.1 compiled with option 35 (with dm+sm). I run real.exe and wrf.exe for one domain without any problem, but when I include two additional nested domains, I only get one input file for d01 and not for d02 and d03. Running mpirun -np 4 ./real.exe, my job terminates after about 12 seconds. (I have managed to get the input files for similar additional nested domains d02 and d03 earlier, so I believe the problem is not related to the installation of WRF.)

I find this error message at the end of the rsl.error files:

At line 777 of file module_date_time.f90
Fortran runtime error: Bad value during integer read

Error termination. Backtrace:
#0  0x15263a93f171 in ???
#1  0x15263a93fd19 in ???
#2  0x15263a940521 in ???
#3  0x15263ab457a6 in ???
#4  0x15263ab49b6c in ???
#5  0x15263ab4ad34 in ???
#6  0x14d1202 in ???
#7  0x1579543 in ???
#8  0x4155f2 in ???
#9  0x415dc1 in ???
#10  0x406d70 in ???
#11  0x152639b81d84 in ???
#12  0x406dad in ???
#13  0xffffffffffffffff in ???

where line 777 in module_date_time.f90 simply reads some date string:

READ(str,33) yr,mm,dd,h,m,s

However, I think my time input in the namelist.input is consistent with the time input in namelist.wps.

Attached are the namelist files and the rsl.error and rsl.out files. Any help would be highly appreciated.

Best regards,


  • namelist.input
    4.4 KB · Views: 3
  • namelist.wps
    954 bytes · Views: 3
    17.8 KB · Views: 0
Your namelist.input looks fine. I don't see any issue with the two namelist files. Please make sure you have met_em.d02 and met_em.d03 files in your working directory.

I did a quick test and there is no problem for the nesting case. Note that my code was built in dmpar mode. It might worth trying to recompile WRF using dmpar mode, then rerun this case.
I have the same error. Did it resolve?

Yes, as far as I remember I found some inconsistencies in one of the met_em files. For some reason, the western part of the domain was shifted to the eastern side of the domain. I found the date for the broken met_em file by looking at the simulation date where wrf stopped running. Rerunning metgrid solved my problem.
I could find some inconsistencies as you mentioned in the metgrid files. I have rerun it and got a successful real run. But the wrf run is showing a similar error. Willl you kindly have a look at my rsl files and namelist?


  • namelist.wps
    840 bytes · Views: 1
  • namelist.input
    4.3 KB · Views: 2
  • rsl.out.0000
    7.8 KB · Views: 1
  • rsl.error.0000
    8.6 KB · Views: 3
In your namelist.inpout, you have the following options

start_year = 2018, 2018,

start_month = 12, 12,

start_day = 10, 08,

end_year = 2018, 2018,

end_month = 12, 12,

end_day = 12, 15,

Note that the start time for child domain should never be earlier than that for the parent domain and the end time should never be late than that of the parent domain. Please change the above options and try again.
是的,据我所知,我在其中一个met_em文件中发现了一些不一致之处。由于某种原因,域的西部被转移到域的东侧。我通过查看 wrf 停止运行的模拟日期找到了损坏的 met_em 文件的日期。重新运行 metgrid 解决了我的问题。
您好,请问您重新运行 metgrid 后生成的 met 文件是否仍然包含错误,或者您在重新运行 metgrid 之前是否进行了其他调整?我的 met 文件也有一些问题;我注意到我的 LUCC 分类只有一个值。此外,这种情况发生在每天的特定时间。您能提供一些指导吗?