RFM v5.0 Release Notes

22NOV17

Overview

RFM v5.0 is a complete rewrite, as well as conversion from Fortran77 to Fortran90 (actually you'll need a compiler for Fortran2003 or later - the code makes extensive use of the MOVE_ALLOC intrinsic function which only came in with F2003).

Apart from requiring different compilation instructions, the inputs/outputs remain the same, at least within the limits of numerical significance, so mostly invisible to the user (see Differences, below). From the user's point of view the main advantage is the automatic array-allocation available with F90, meaning no more editing of rfmsiz.inc and recompiling whenever an array dimension has to be increased.

From my point of view it's a chance for a simplification (bearing in mind that the original code has evolved hapharzardly from its original incarnation in 1995 as a limb radiance simulator for MIPAS) which should make it easier for me to add/change/fix things. On the other hand, being almost entirely new code, it will have a whole new set of bugs.

Differences

From the RFM v4.3 user's viewpoint, these are the main changes
RFM Runlog file
The name is changed from rfm.runlog to rfm.log for consistency with 3-character extensions of other RFM filenames. If you really still want the old version, edit the OPEN statement in rfm.f90
LUN Flag
Ignored (with a warning message). No longer required since the new architecture doesn't require multiple output files to be kept open (see Internal Structure).
TPS Flag
No longer supported. The 4th-order Lagrangian interpolation from tabulated values at 25K intervals introduced in RFM v4.3 is probably of comparable accuracy to the linear interpolation from the 1K data in the raw TIPS data files.
V42 Flag
No longer supported. I'm assuming by now everyone will be accustomed to RFM v4.3 and no longer require compatibility with RFM v4.2
REJ Flag
Now redefined to do something more useful.

New Features

The following new features are implemented in RFM v5.0
*GAS Section
Arbitrary molecules can be specified by the user, as long as they have a corresponding profile in the *ATM section and cross-section data in the *XSC section. (Only new x/s molecules can be specified in this way since line molecules require additional data such as mass and partition sums which are not present in the HITRAN line parameters).
*HIT Section
HITRAN line data can now be used in the original 160 character record form (.par files) as well as the binary form created by the hitbin program. It's slower but if you just want a one-off RFM calculation it saves the extra step of having to convert the HITRAN data to binary form.
*XSC Section
HITRAN x/s data can now be used in the original form downloaded from the HITRAN web-site, as well as the RFM-modified form created by the hitxsc program. Again saving having to run the conversion program but in this case only a negligible cost in speed.

Code Conventions

Firstly, an acknowledgement for Clive Page (U.Leicester) for his valuable Fortran90 for Fortran77 Programmers.

The F77 version of the RFM was split into *.for and *.inc files, the latter containing common data or constants. In F90 these are all replaced by 'modules' with the extension *.f90, although I've added further information in the module names:

Generally each module will enclose a single subroutine or function of the same name, eg module abcdef_sub.f90 contains just the subroutine ABCDEF. The exceptions are the Generic modules which contain a set of functions or subroutines which all perform the same operation but on different types of input variables (eg real, double precision) - one of the new features available with F90.

Internal Structure

The top level program rfm.f90 is now much simpler with a clear division into three separate components The F77 RFM progresses through each spectral range writing each 1 cm-1 interval as it is calculated, and only stores the current and previous intervals, which imposes a limit on the width of any spectral convolution that could be applied. The F90 RFM stores the full spectrum, with convolution and output saved until completion of the spectral calculation. This requires more memory but allows arbitrarily wide ILS convolutions and only opens/writes/closes output files one at a time, using the same logical unit number, rather than keeping a large number of files open, so the LUN flag is no longer required.

CPU Impact

Since F90 allows whole-array operations rather than element-by-element, it ought to run faster. However, with compilers such as ifort, I can't say I've noticed any significant improvement in speed. In fact, it takes longer to compile, but this won't be something that has to be done often.

Compilation

One of the features of F90 is that module interfaces are checked on compilation, eg making sure the ordering and type of variables in the argument list to a subroutine is consistent with the argument list that the subroutine expects. This does, however, mean that the compilation has to be performed in a particular order, creating *.mod files with the necessary interface information. For this reason the F90 RFM comes with a 'make' file (see
F90 compilation).