Running the RFM
Contents
05JAN24

Single Run

The program is run in the same way as any other executable under Linux/Unix, for example entering a command in an x-term window.

Assuming that the RFM executable file rfm has been compiled in, for example, relative directory ./RFM/source/, type

./RFM/source/rfm
If the exectuable is in the local directory (or folder), depending on the nuances of the linux system, you may be able to simply type rfm or you might need
./rfm
The program will expect a file rfm.drv in the local directory. This is the Driver Table, an editable text file which controls the RFM operation. Unless otherwise directed (via the Driver Table), all output files will also be created in the local directory. A single run of the RFM typically produces spectra for one or more viewing geometries over one or more spectral ranges, as specified in this Driver Table.

Running the RFM for a single spectral range spanning a 5 cm-1 interval might generate the following terminal output:

./RFM/source/rfm R-RFM: Running RFM v5.10 I-RFMSPC: Widemesh calculation ... I-RFMSPC: Finemesh calculation ... 1 5 2 5 3 5 4 5 5 5 R-RFM: Successful completion

The R-RFM: ... messages are routine status information, the first one indicating the version of the RFM is being run. This version identifier also appears in the first header record of all output files.

The Widemesh calculation... message, indicating the start of the first, low spectral resolution pass through the data, usually appears almost instantaneously. This also indicates that the Driver Table has been successfully read and checked so, after this message appears, it is safe to alter, delete or move the Driver Table.

Since almost all errors are likely to occur as the Driver Table is being read and checked, it is usually safe to assume that the code will now run to a successful completion.

Finemesh calculation ... indicates the start of the high spectral resolution calculation. The following sequence of number pairs refer to the current wavenumber interval processed and the (fixed) total number required (in this case, 5 for the 5 cm-1 range, although it could be 6 if the last point is at the start of the next wavenumber interval, or more if any spectral convolution is applied).

Since the Finemesh calculations are the time-consuming part of any major run of the RFM, these messages give some indication of progress towards completion, but they can be suppressed by the SHH flag.

The 'R-RFM: Successful completion' message indicates a successful completion, i.e. no fatal errors. Any 'underflow' messages can be ignored.

If, for some reason, a fatal error occurs the program will halt and print a message to the terminal beginning with 'F-' (see Error Messages).

It is possible that various 'warning' (rather than 'fatal') conditions may have arisen, beginning with 'W-', which will be listed in the rfm.log file.

Multiple Runs

Since each run of the RFM expects a Driver Table with the fixed name rfm.drv, the easiest way to set up multiple runs is to start with a set of driver tables of names, e.g., rfm_a.drv, rfm_b.drv ... and create a shell script to cycle through them, as in the example below:
#! /bin/sh # loop through all files rfm_*drv linking to name rfm.drv for i in rfm_*.drv do ln -f $i rfm.drv ./RFM/source/rfm < inprfm_$$ done exit 0
For those not familiar with shell scripts, copy the contents of the above box into a file e.g., rfm.sh, changing the location of the RFM executable as necessary. Then, to make this an 'executable' script, type
chmod +x rfm.sh
You should then be able to run it in the same way as an executable program, ie simply type rfm.sh, and it will then run sequentially through all the driver files that fit the pattern rfm_*.drv. One warning, though: the rfm.log file is overwritten each time.

Run_ID

The Run_ID is an optional text string which the user is prompted to enter when the RFM starts. This text string is then appended to the names of all output files, including rfm.log, to give a simple way of distinguishing different runs. (This can also be done using the *OUT section of the driver table, but the Run_ID is simpler and also changes the the rfm.log filename.)

Note that this only affects the output filenames and not the contents of the output files themselves.

This feature is switched off in RFM v5 but, to switch it on, edit the main program module rfm.f90 and change the constant PROMPT from .FALSE. to .TRUE.

! LOCAL CONSTANTS
LOGICAL, PARAMETER :: PROMPT = .FALSE. ! T=prompt user for appended ID

On starting, the RFM will then prompt the user (via the terminal) for an optional 'run_ID', which can be any contiguous text string (ie no spaces) of up to 80 characters.

./RFM/source/rfm R-RFM: Running RFM v5.02 Optional ID to be appended to filenames (<CR>=none): _test R-RFM: Filename append string=_test I-RFMSPC: Widemesh calculation ... I-RFMSPC: Finemesh calculation ... 1 5 2 5 3 5 4 5 5 5 R-RFM: Successful completion
In the above example, the string '_test' was used, thus creating output files with names rfm.log_test, rad_01000.asc_test etc.

One could also just type <CR>, in which case nothing will be appended.

Since entering the Run_ID requires a user terminal input, even if it is just a <CR>, this complicates writing a script to perform with multiple runs of the RFM. One solution is to create a dummy file containing just a blank line:

Example of a shell script which runs a series of RFM driver tables responding to the Run_ID prompt with a <CR>
#! /bin/sh # create a temporary file containing just the <CR> terminal response cat <<EOF>> inprfm_$$ EOF # loop through all files rfm_*drv linking to name rfm.drv for i in rfm_*.drv do ln -f $i rfm.drv ./RFM/source/rfm < inprfm_$$ done # delete the temporary file rm inprfm_$$ exit 0