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 stops with no error v3.9.1

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

Grad student looking for some guidance running wrf 3.9.1, and wondering if you all can provide assistance.

Real.exe successfully completes without error or problems and produces all required files wrfinput/wrfbdy for wrf.exe. When I run wrf.exe, it just stops with no fatal error, warnings, or segmentation faults. Nothing in the rsl.error or rsl.out files seems to be amiss, it just stops. I've bumped my debug level up to 9999 to provide any additional info, but nothing jumps out at me saying there's a problem.

View attachment namelist.input

View attachment rsl.error.0000.txt

View attachment rsl.out.0000.txt

I greatly appreciate any help/input that you can provide me.
The problem is likely that you are using too many processors. Take a look at this FAQ post regarding how to determine a good number of processors, and why using too many can cause failures:

A couple of additional things I'd like to suggest:
1) You you want to consider making your domain a little larger. We do not recommend ever using a domain smaller than 100x100 because there isn't enough room for systems to fully propagate through the domain to affect the run. You are essentially using the boundary conditions to run the model, without any additional calculations. Take a look at this web page that not only describes all of the commonly-used namelist parameters, but also gives best practices methods for setting up a good domain:
(if you're interested, there is one for WRF too:

2) You should set 'debug_level' back to 0. This parameter was implemented several years ago for a particular developmental purpose and is rarely useful for any debugging purposes. Instead it simply adds a lot of junk to your rsl* files, making them difficult to read.

Have you tried look in rsl.error.0001, rsl.error.0002 etc.?

Sometimes I have noticed that an mpi abort can be logged in them but not in rsl.error.0000. Worth a check. This also does not happen consistently which is annoying.

Hope that helps.
Hi everyone, thanks for the responses! I was able to resolve (or work around) the error by modifying my domain setup, which was easy enough to handle. Not a bad idea to check some of the other rsl.out/rsl.error files beyond the 0000 though...