RFM Installation | ||
16MAY24 |
The RFM uses no external libraries so you just need the source code.
RFM v5.0 is written in Fortran90 (actually using some features introduced with Fortran2003) and any generic Fortran compiler should work (eg gfortran, ifort). Since it uses dynamic array allocation the memory requirements are set during run time.
For RFM v5.0 this expands to produce a single
program module (rfm.f90) plus around 350
other *.f90 files containing either
subroutines or data modules, plus one makefile.
On Windows systems you can use eg WinZip if you already have it,
or 7-Zip which is free. You might need to 'unzip' the package twice, the first
to undo the .gz and the second to unpack the .tar to produce a regular
folder.
Fortran90/2003 compilation is a bit more complicated than the old Fortran77
since it
requires the creation of intermediate *.mod files (basically containing
information on interfaces between different modules) and so requires
compiling in a particular order to ensure that the *.mod
files of, say, any
called subroutines already exist.
You could just use the sledge-hammer approach (and I have a certain
sympathy with that): just repeatedly typing something like
A more sophisticated approach is to use the makefile
provided in the delivery and just type
The provided makefile uses a specific compiler (gfortran)
and compilation switches (-fbounds-check -Wall), and you'll probably have
your own preferences, in which case edit the relevant lines in the
makefile
Any queries or reports on possible new bugs
should be emailed to:
anu.dudhia@physics.ox.ac.uk
I generally aim to respond within one working day, but if it's a suspected bug,
I'm likely to want a copy
of the rfm.log file, the
rfm.drv file and (if it's small!) any input file
you suspect is causing the problem, so please attach these to your email.
Unpacking the RFM tar file
The source code is distributed as a compressed (with gzip)
tar file.
To unpack the code, place the tar file (eg named
rfm_v5.20.tar.gz) into an empty directory/folder and (with linux) type
Compiling the RFM
which will initially create a large number of warnings about missing
modules but, after about 8 or 9 attempts, will eventually be satisfied
that everything is in order and create an executable called rfm
The IDL program used to generate the
makefile
relies on a very specific code structure within each module so is unlikely
to be of much use to anyone else, but if you're interested it's:
make.pro
Making Local Modifications
There is a CHARACTER*11 variable VIDHDR
set at the start of the executable code in the main program module
rfm.f90,
which is written as part of the output file
headers. To allow traceability
between spectra generated by different versions of the RFM code,
any local modifications to the RFM code should be reflected in this field.
E.g., to represent a local Oxford modification 13 to the
standard version '5.10', I might use:
But of course it's up to you to decide how to represent this information
in VIDHDR
Queries & Bug Reports
A list of all reported bugs (and fixes) is maintained
[here].
Bug reports are encouraged!