Difference between revisions of "Common GEOS-Chem error messages"
(New page: Here is a list of some commonly-encountered GEOS-Chem error messages. == Exit Status == If you submit a job to the PBS Queue, the exit status will tell you a little bit about what happen...)
Revision as of 18:40, 26 March 2008
Here is a list of some commonly-encountered GEOS-Chem error messages.
If you submit a job to the PBS Queue, the exit status will tell you a little bit about what happened. The exit status code is in the email that you will get back from the PBS server:
PBS Job Id: 6015.altix Job Name: test.sh Execution terminated Exit_status=1 resources_used.cpupercent=0 resources_used.cput=00:00:00 resources_used.mem=2304kb resources_used.ncpus=1 resources_used.vmem=4544kb resources_used.walltime=00:00:00
Jobs that finish normally should have an exit status of 0. In the above example, we have an exit status of 1, which means that the job encountered some kind of error (either a compilation error or a run-time error).
A common exit status number is 143. This means that your job has exceeded the wall-clock time limit of the queue. The solution is to restart your job in a queue with a longer time limit.
A segmentation fault may mean:
- You have gone outside the declared bounds of an array
- You are trying to access an ALLOCATABLE array that hasn't been allocated yet
- You are trying to read data from a file into an array of the wrong dimensions
Here is segmentation fault caused by the code trying read data from a file into an array which is too small to contain the data. This error was detected on the Altix platform. The output comes from the IDB debugger.
Thread received signal SEGV stopped at [<opaque> for_read_seq_xmit(...) 0x40000000006b6500] Information: An <opaque> type was presented during execution of the previous command. For complete type information on this symbol, recompilation of the program will be necessary. Consult the compiler man pages for details on producing full symbol table information using the '-g' (and '-gall' for cxx) flags.
The same error message as in Example 1 has also been known to occur on Altix when a variable that has not been initialized is passed to a subroutine or function:
CALL MYSUB( I ) ! I is uninitialized! DO I = 1, IIPAR ... ENDDO
The solution to the problem is as follows:
DO I = 1, IIPAR CALL MYSUB( I ) ! Put the MYSUB call in the I-loop! ... ENDDO
A bus error usually means that you are trying to call a subroutine with the wrong number of arguments.
On SGI, you usually will only get a bus error if you call a subroutine with too many, rather than too few arguments. Other behaviors are platform and compiler dependent.
Sometimes you might encounter a weird error during GEOS-Chem compilation. Here is an example.
Example: Fatal Error on Altix
The following error, which resulted on the Altix platform using Intel "ifort" v9 compiler:
ifort: error: /opt/intel/fc/9.0/bin/fpp: core dumped ifort: error: Fatal error in /opt/intel/fc/9.0/bin/fpp, terminated by unknown signal(139) make: *** [transport_mod.o] Error 1
was caused by an omitted " in an #include declaration, i.e.
# include "CMN_DIAG
Adding the closing " fixed the problem.