There are a couple of ways to try to debug the code.
1) For a small domain that can be run on only 1 processor, you can use the GNU debugger:
./clean -a
./configure -D (choose a serial compilation)
And then recompile. When you run the code, in the command line, issue
gdb ./wrf.exe
When prompted, enter: run
The model should stop right on the line that is causing the error. You can type 'list' to get more information, or type 'quit' when you're done.
2) For larger domains, or to turn on bounds checking, tracebacks, etc.,
./clean -a
./configure -D
And then recompile.
Run the model, and when it fails, check the error or out logs, which should print the line of code that caused the model to fail.
We DO NOT recommend setting debug_level in the namelist.input file. This option was removed in V4.0 because it rarely provided useful information and just added a lot of junk to the log files, making them difficult to read.
1) For a small domain that can be run on only 1 processor, you can use the GNU debugger:
./clean -a
./configure -D (choose a serial compilation)
And then recompile. When you run the code, in the command line, issue
gdb ./wrf.exe
When prompted, enter: run
The model should stop right on the line that is causing the error. You can type 'list' to get more information, or type 'quit' when you're done.
2) For larger domains, or to turn on bounds checking, tracebacks, etc.,
./clean -a
./configure -D
And then recompile.
Run the model, and when it fails, check the error or out logs, which should print the line of code that caused the model to fail.
We DO NOT recommend setting debug_level in the namelist.input file. This option was removed in V4.0 because it rarely provided useful information and just added a lot of junk to the log files, making them difficult to read.
Last edited: