RFM Error Handling


Error Handling

The RFM should trap all error conditions and terminate with an error message printed to the terminal of the form
F-ABCDEF: ....
where ABCDEF is the Fortran module in which the error occurred (i.e. file abcdef_sub.f90). These messages are also printed to the
log file (unless writing to the log file itself caused the error).

Exceptions are

Common Errors

Most errors will be for either of two reasons
  1. I/O Errors on input/output files
    The IOSTAT Status code will also be printed. This is the integer status variable associated with Fortran I/O operations. Unfortunately, the values are compiler-dependent (see for example
    GNU Fortran Run-Time Library Errors). Check the end of the log file to see the name of the file that the RFM was attempting to access.

  2. Driver Table errors
    Due to incorrectly formatted Driver Table. These often (but not always) begin with F-DRVXXX where XXX is the name of the Driver Table section. Check the end of the log file to find the last section being read. If it's an error associated with the last section in your driver table which, to you, looks to be perfectly OK it could be because you've forgotten to insert a <CR> (Return) character at the end of the *END record.
Most of these failures will occur before the Wide Mesh Calculation starts. Once the RFM gets into the Wide Mesh Calculation the most likely source of any error will be due to computer memory or disk space problems associated with writing the output spectra.

Other Errors

  1. With Linux, a problem may arise when reading ASCII files for the first time due to unreadable linefeed or carriage-return characters. These give IOSTAT=112 using the Gnu compiler, or IOSTAT=173 using the Fujitsu "f95" compiler. These characters can be removed using
    perl -pe "s/\r//" infile.asc > outfile.asc
    (If you have it, the command dos2unix does the same thing)

  2. It is also possible that the program terminates with an error message printed to the terminal of the form:
    F-ABCDEF: Logical Error
    These are logic checks within the code, eg checking for running off the end of a DO loop when it isn't supposed to happen. If you get one of those it means that there is a
    bug in the code, so please inform me (email: anu.dudhia@physics.ox.ac.uk)

  3. With the ifort compiler, the code can suddenly crash with a segmentation fault error (SIGSEGV). This is associated with too much memory being required. See [Intel Web-page] for various solutions.