RFM v5.0 Release Notes
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,
within the limits of numerical significance, so mostly invisible to the user
(see Differences, below).
user's point of view the main advantage is the automatic array-allocation
available with F90, meaning no more editing of rfmsiz.inc and
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.
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.
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
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.
Firstly, an acknowledgement for Clive Page (U.Leicester) for his valuable
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
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.
- *_sub.f90 Subroutine
- *_fnc.f90 Function
- *_gen.f90 Generic Subroutine/Function
- *_dat.f90 Global variables or constants (approx old *.inc files)
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.
- Read the driver table
- Set up ray paths
- Loop through required spectral ranges
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.
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).