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.

J

Jslaten

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.
Code: 
 42 INITIALIZE THREE Noah LSM RELATED TABLES
 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
 

Attachments

Hi,
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.

Code: 
 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?

-Jesse
 
Jesse,
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.
Ming
 
You must log in or register to reply here.
Back
Top