Linux f90 code written by Tim Mitchell
readme file, 24.2.04

I have written a fairly substantial volume of f90 code in the past few years, mostly
to cope with all the data-sets I have been handling. I have done almost all my data
manipulation in f90, and almost all my data plotting in idl.

The code in this directory was (mostly) originally written in Compaq f90 on crua6,
and was (mostly) subsequently ported to work under the Portland Group f90 compiler 
on the UEA Beowulf cluster (beo1.uea.ac.uk).
This code has been ftp'd back to here to be within reach of crua6 users. Where I have
had the opportunity, I have ported the code back to crua6. This equivalent crua6 code 
may be found in ./../alpha 

The compilation statements in the headers of the main programs will use the pgf90 command
if the program has been ported across to the Beowulf cluster. If I never got around to 
porting, the statements will use the f90 command. If you want to use an unported f90 program 
on the Beowulf cluster, find a pgf90 program and copy the syntax. It should mostly work. 
Exceptions may include:
a. Hard addressing of dump files in the main program (search for 'f709762')
b. Reading the number of lines in a file (via a shell call wc -l) as i10 instead of i8
c. Passing a pointer array to a subroutine, subsequently allocated in the subroutine and
	returned to the main program; for some unknown reason this works fine on crua6 but
	not (or erratically?) on beo1. If you get a segmentation fault, suspect this!
	No easy solution, because I use this construct extensively. You may need to rewrite
	the code to allow two calls. Call the subroutine once to find the dimensions of the
	arrays, then allocate the arrays in the main program, then call the subroutine again
	to fill the arrays. Good luck!
d. Calling a subroutine that has been subsequently modified since I last compiled the main
	program. Check that the variables passed to/from the subroutine are the same in the
	main program and in the subroutine. Changes are usually noted in the subroutine headers.

If anyone wanted to run this software on the Beowulf cluster, it should be quite simple.
1. Copy this directory across to your user area on the cluster. 
2. Ensure that there is a suitable dump directory into which log files can be written.
3. Locate the main program that you want to use.
4. Ensure that the main program writes to a log file in the dump directory.
5. Go to the mod subdirectory. 
6. From the mod subdirectory use the compilation statement in the headers of the 
	main program in which you are interested. (These have optional optimisation.)
7. Execute the compiled program.

Bear in mind that the software is designed to run on data-sets in the formats that I use, 
so you will need to have access to those files on the Beowulf cluster for this software
to be useful on the Beowulf cluster.

The reason that the compilation statements in the headers are designed to be executed from
the mod subdirectory is that most main programs use a large number of modules designed
to be used with a variety of programs. The compilation statements are a lot shorter when 
executed from the mod subdirectory. That is the only reason.