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

Bad wrfbdy file created after ndown.exe?

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 everyone,

I'm currently trying to run a one-way nested run using ndown and I'm using this guide from UCAR (

I have already done my first domain simulation (9km) and everything seems to be OK after checking the errors logs, but when I run the real.exe of the d02 (3km), simulation crashes after creating the first timestep. After some examination, I have realised that the wrfbdy created for this domain after executing ndown.exe has [-Inf, Inf] values on most of the wind fields, so I must suppose this is behind the failed run. This doesn't happen on the wrfbdy of my previous successful files. What can I do to fix this? Can this be also related to the fact that my 3km domain contains a large part of complex topography?

I am currently using WRF v4.3 and using ERA5 as forcing. Attached is my namelist.input, a figure of the topography of my domains, error log from running the 3km simulation with wrf.exe, and a sample of wrfbdy_d01 (of the 3km domain)

Thank you in advance,



  • domains.png
    52.4 KB · Views: 119
  • namelist.input.2doms.txt
    3.9 KB · Views: 11
    100.9 MB · Views: 7
  • rsl.error.0000.txt
    22.1 KB · Views: 7
Hi Ricardo,
The rsl file you sent is for a wrf.exe run, but you mention you get this failure when running real.exe, and this inquiry is posted under the "real.exe" section of the forum. Did you mean wrf.exe?

Out of curiosity, what is your reason for wanting to run the ndown program, as opposed to a regular nested simulation? Typically this program is reserved for very large/long simulations (e.g., many years) in which someone runs d01 and then later decides to insert a nested domain, or for cases when the size difference of d01 and d02 are so different that it's impossible to use the same number of processors for both domains together. It doesn't seem that your set up meets either of those criteria, so just thought I'd ask to make sure it's reasonable to use ndown. Thanks!
Dear kwerner,

Oh yes, my bad. I meant to post this in the wrf.exe section. But the problem (i think) i am having is regarding the boundary file created after ndown.exe.

Regarding the simulation period, I am doing this run for testing purposes. I am planning to do several years simulations later on the future. But first I would like to make this ndown run successfully.


Ok, thanks for the explanation. As a test, can you run the simulation as a standard nested run (both domains at the same time) and you can set "feedback = 0" so it will run as a 1-way simulation? I'm curious whether this will give similar issues, or if it is strictly related to the ndown program.

If it also stops immediately, an initial thought is that you're not using enough processors. Your domain 02 is ~300x300 and you likely need more than 4 total processors to run a domain that size. If that's not the issue, please package all of your rsl* files together as a single *.tar file (not *.rar) and attach that for me, along with the namelist.input file used for running the failed wrf.exe simulation. Thanks!
Dear kwerner,

Thank you for your response. I have previously run the simulation as a one-way nest with 32 procs without any problem. Indeed, I would say that this is very likely to be related to ndown outputs and not really to wrf.exe.

Now, I have assigned 16 procs to the 3 km single domain simulation. The only difference between this run and the previous run with only 4 procs is that it doesn't show SIGSEGV errors any longer, but it still dies after the first time step. I have also tried reducing the time step drastically (dt = 1/1000 seconds), but the simulation remains with the same fate.

Attached files are my single domain namelist.input and the package of rsl logs

Thank you in advance!



  • rsl_logs.tar
    200 KB · Views: 5
  • namelist.input
    3.7 KB · Views: 4
Thanks for confirming that. If you look at some of the rsl files (e.g., rsl.error0011), you do still see the segmentation fault. This is difficult to address with this information, so I'd like to request your input so I can test this myself. Please provide all the files I'll need to run through the ndown process (appropriate namelists, wrfbdy* wrfinput* wrfout_d01). These files will likely be too large to attach here, so take a look at the home page of this forum for instructions on sending large files. Thanks!