Debugging GEOS-Chem

On this page we provide information that you can use to debug errors that may arise in your GEOS-Chem simulations.

Overview

If your GEOS-Chem simulation dies unexpectedly with an error or takes much longer to execute than it should, the most important thing is to try to isolate the source of the error or bottleneck right away. Below are some of debugging tips that you can use.

Also see the Common GEOS-Chem error messages wiki page for detailed information on common errors and how to resolve them.

Debugging tips

Check the GEOS-Chem and HEMCO log files

If your GEOS-Chem simulation stopped with an error, but you cannot tell where, turn on the ND70 diagnostic (debug output) in input.geos and rerun your simulation. The ND70 diagnostic will print debug output at several locations in the code (after transport, chemistry, emissions, dry deposition, etc.). This should let you pinpoint the location of the error.

If the log file indicates your run stopped in emissions, you can check the HEMCO.log file for additional information (GEOS-Chem v10-01 and later versions only). We recommend setting both the Verbose and Warnings options in HEMCO_Config.rc to 3 to print all debug statements and warning messages to your HEMCO.log file.

If your run stopped with an erorr, see the Common GEOS-Chem error messages wiki page for detailed information on common errors and how to resolve them.

Make sure you did not max out your allotted time or memory

If you are running GEOS-Chem in on a shared computer system, chances are you will have used a scheduler (such as LSF, PBS, Grid Engine, or SLURM) to submit your GEOS-Chem job to a computational queue. You should be aware of the run time and memory limits for each of the queues on your system.

If your GEOS-Chem job uses more memory or run time than the computational queue allows, your job can be cancelled by the scheduler. You will usually get an error message printed out to the stderr stream. Be sure to check all of the log files created by your GEOS-Chem jobs for such error messages.

The solution will usually be to submit your GEOS-Chem simulation to a queue with a longer run-time limit, or larger memory limit. You can also split up your GEOS-Chem simulation into several smaller stages that take less time to complete.

Check if someone else has already reported the bug

Before trying to debug your code, we recommend that you check our Bugs and fixes wiki page to see if your error is a known issue, and if someone has already submitted a fix.

Recompile GEOS-Chem with debug options turned on

Check for common problems like array-out-of-bounds errors, floating-point exceptions, and parallelization issues by turning on debug compiler switches:

Debug options for GEOS-Chem Classic simulations

Compile GEOS-Chem classic with the options listed below. Then run a GEOS-Chem simulation and check the log files for error messages.

Debugging flag	Description
DEBUG=yes	This option turns off all optimization. It also prepares GEOS-Chem so that it can be run in a debugger like TotalView.
BOUNDS=yes	This option turns on runtime array-out-of-bounds checking, which looks for instances of invalid array indices (i.e. If the A array only has 10 elements but you try to reference A(11).)
TRACEBACK=yes	This option turns on the -traceback option (ifort only) and will print a list of routines that were called when the error occurred. NOTE: This option will always be turned on by default in GEOS-Chem v11-01 and newer versions.
FPEX=yes or FPE=yes	This option turns on error checking for floating-point exceptions (i.e. div-by-zero, NaN, floating-invalid, and similar errors).
OMP=no	This option turns off OpenMP parallelization (which is turned on by default). This will check for parallelization issues.

Debug options for GCHP simulations

To debug a GCHP simulation, follow these steps:

1. In file GCHP/Shared/Config/ESMA_base.mk change the flag BOPT = O to BOPT = g
2. Cleanup the GCHP directory with make clean_all.
3. Recompile GCHP from scratch using the option make compile_debug
4. Submit a GCHP simulation and check the log files for error messages.

--Bob Yantosca (talk) 16:34, 21 December 2018 (UTC)

Identify whether the error happens consistently

If the error happens at the same model date & time, it could indicate bad input data. Check our List of reprocessed met fields to make sure there is not a known issue with the met fields or emissions for that date. This is a list of met field data files that had to be regenerated due to known issues (i.e. incomplete data or other such problems). You might be able to fix your problem by simply re-downloading the affected file or files.

If the error happened only once, it could be caused by a network problem or other such transient condition.

Run GEOS-Chem in a debugger to find the source of error

If you have access to a debugger (e.g. GDB, IDB, DBX, Totalview), you can save a lot of time and hassle by learning the basic commands such as how to:

• Examine data when a program stops
• Navigate the stack when a program stops
• Set break points

To run GEOS-Chem in a debugger, you should add the DEBUG=yes option to the make command. This will compile GEOS-Chem with the -g flag that tells the compiler to generate symbolic debug information. The DEBUG=yes option also uses the -O flag, which switches off compiler optimization that can modify the sequence in which individual instructions occur. To apply these options, type:

     make -j4 DEBUG=yes OMP=no    # Without parallelization
     make -j4 DEBUG=yes           # With parallelization

Isolate the error to a particular operation

Can you tell if the error happens in transport, chemistry, emissions, dry dep, etc? Try turning off these operations one at a time in input.geos to see if you get past the error.

Also try turning on the ND70 diagnostic, which will add additional debug print statements to the output. This will help you to see the last subroutine that was exited before the error occurred.

Check any code modifications that you have added

If you have made modifications to a "fresh out-of-the-box" GEOS-Chem version, then you should look over your changes to search for the source of error.

You can also use Git to revert to the last known error-free state of GEOS-Chem, and use that as a reference.

Check for math errors

If you suspect that a floating-point math error, such as:

• Division by zero
• Logarithm of a negative number
• Numerical overflow or underflow
• Infinity

Then make clean and recompile with the FPEX=yes flag. This will turn on additional error checking that will stop your GEOS-Chem run if a floating-point error is encountered.

You can often detect numerical errors by adding debugging print statements into your source code:

• Check the minimum and maximum values of an array with the MINVAL and MAXVAL intrinsic functions:

     PRINT*, '### Min, Max: ', MINVAL( ARRAY ), MAXVAL( ARRAY )
     CALL FLUSH( 6 )

• Check the sum of an array with the SUM intrinsic function:

     PRINT*, '### Sum of X : ', SUM( ARRAY )
     CALL FLUSH( 6 )

See our Floating point math issues wiki page for information on how to avoid some common pitfalls.

When in doubt, print it out!

Print out the values of variables in the area where you suspect the error lies. You can also add call flush(6) to flush the output buffer after writing. Maybe you will see something wrong in the output.

When all else fails, use the brute force method

If the bug is difficult to locate, then comment out a large section of code and run GEOS-Chem. If the error does not occur, then uncomment some more code and run GEOS-Chem again. Repeat the process until you find the location of the error. The brute force method may be tedious, but it will usually lead you to the source of the problem.

Using profiling tools to determine the source of computational bottlenecks

If you think your GEOS-Chem simulation is taking too long to run, consider using profiling tools to generate a list of the time that is spent in each routine. This can help you identify badly written or parallelized code that is causing GEOS-Chem to slow down. For more information, please see our Profiling GEOS-Chem wiki page.

Using the GEOS-Chem Unit Tester

The GEOS-Chem Unit Tester is an external package that can run several test GEOS-Chem simulations with a set of very strict debugging options. The debugging options are designed to detect issues such as floating-point math errors, array-out-of-bounds errors, inefficient subroutine calls, and parallelization errors. You can use this tool to find many common numerical errors and programming issues in your GEOS-Chem code.

For complete instructions on how the GEOS-Chem Unit Tester can assist your debugging efforts, please see our Debugging with the GEOS-Chem unit tester wiki page.

Contacting the GEOS-Chem Support Team for assistance

If you have tried to solve your code problem but cannot, then please report it to the GEOS-Chem Support Team. We will be happy to assist you. In order for us to diagnose your issue, we request that you send us the following items:

For a list of items to include in your GEOS-Chem support request, please see our Submitting GEOS-Chem support requests wiki page.

--Bob Yantosca (talk) 16:39, 21 December 2018 (UTC)