RFM Error Handling


Error Handling

The RFM should trap all error conditions (apart from numerical overflows) 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
rfm.log file (unless writing to the runlog file itself caused the error).

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 rfm.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 rfm.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 the chances are it's because you've forgotten to insert a <CR> character after the *END record (see Note 2).
Most of these failures will occur before the Wide Mesh Calculation starts. The most likely exception is running out of diskspace, which may result in an I/O error at any point during the run.

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 > 
    (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's a
    bug in the code, so please inform me (email: anu.dudhia@physics.ox.ac.uk)