7. Programmers Notes

** COMPILERS and PLATFORMS **

Digital Unix Fortran Compiler + OSF/1:
All codes run satisfactorily on Digital/Compaq Alpha processors.

Intel Fortan Compiler + Linux:
All codes compile. SPECTRUM has been verified. STERNE ok for continuum models, but does not read opacity distribution functions. SFIT fails

Nag Fortran Compiler + Linux:
All codes compile. SPECTRUM not verified. STERNE fails. SFIT ok.

g77 + Linux:
All f77 codes compile. SPECTRUM not verified recently. STERNE fails. SFIT = f90.

** INCLUDE FILES and MODULES **

The reason for this is historical. In f77 the INC|LUDE statement enabled the creation of common code that could be shared between subprogram units. This was particularly useful for providing global variables through COMMON blocks. However, the practice of using subroutine libraries as distinct from a monolothic program is only really effective when such shared code remains internal to the library, all communication between external program units and library programs being via subroutine arguments. Therefore there is a distintion between private COMMON (seen only by the subroutine library) and global COMMON, but this is a semantic distinction only. My convention is to place INCLUDE files containing global COMMON variables in a defined folder in the software folder structure currently ./include (to be replaced by ./inc when I have debugged all the references).

In f95, the use of INCLUDE is deprecated and replaced by the use of MODULE subprogram units. The distinction between private and global variables remains, but, in principle, there is a more legitiamte way to export "global" varaibles from a subroutine library than simply making the INCLUDE file globally visible. Thus, on compiling and linking the program, a reference to USE a MODULE in a subroutine libarary should be resolved without having to specify it manually. In practice, some f95 compilers deal with this satisfactorily (for example, the NAG Fortran90 Compiler and the Digital Unix Fortran Compiler). I have not yet worked out how to make the Intel Fortran Compiler do this.

** WARNING **

When you start hacking the real code, it is very important to do a 'make update' frequently when editing programs. My makefiles currently have a tendency to think that the text libraries are more recent than the piece of code just edited, so a program gets re-extracted and clobbers you're recent edits.