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

wrf.exe Error in opening wrfbdy_d01 IERR = -1021

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.


New member
Hi all,

I received this error upon testing a simulation and I had not seen anything similar browsing the forum.
Here is a snippet of the error.
 43 Computing time series locations for domain   1 starting from 2017-04-03_12:00:00
 44  mediation_integrate.G        1944 DATASET=HISTORY
 45  mediation_integrate.G        1945  grid%id            1  grid%oid            1
 46 -------------- FATAL CALLED ---------------
 47 FATAL CALLED FROM FILE:  <stdin>  LINE:    1834
 48  med_latbound_in: error opening wrfbdy_d01 for reading. IERR =        -1021

Attached are my namelist.input , namelist.wps , and rsl file.

Thanks, Jesse


  • namelist.input
    3.6 KB · Views: 42
  • rsl.error.js
    4 KB · Views: 24
  • namelist.wps
    723 bytes · Views: 26
Can you check whether wtrfbdy_d01 exists in your working directory? if so, please type the command: ncdump -v Times wrfbdy_d01. You should have 4 times of data in wrfbdy_d01.
In your namelist.input, the start and end time are the same, but you specify the run_hour = 5. I am not sure whether this will cause trouble in producing wrfbdy_d01.
I notice that this is a very high resolution run (dx=300m). What data did you use to force this case?
Hello and thank you for the help.

It turns out the wrfbdy_01 file was not created :^) . I had an incorrect time in the namelist.input file in the input_seconds var the correct time is GFS files every 6 hrs. So that was fixed as such.

 interval_seconds                    = 21600

After that I re-ran ./real.exe and successfully made wrfbdy_d01. When I ran ./wrf.exe this has removed the error. As for the resolution I had wanted to get about as fine as I possibly could but do you think that is not possible given the resolution of the GFS data?

Thanks for the description of the issue. I am glad that this problem is solved.
Regarding your question of this case, I don't think GFS can work fine to drive this case. Your resolution is 0.3km and the grid numbers is around 100. This means that the entire domain is roughly within a single GFS grid.
You need to either increase the grid interval, increase the number of grids, or use some other high resolution data as forcing for this case.