^{The source code for MOFIA 2.0 is in the directory mofia/2.0/source. Several subdirectories reside in it: main, mainf90, dummy, include, modules, photo, and user. The subdirectory main contains the MOFIA "mainframe" code (adapted from E787); this is the part that was not changed and is still in FORTRAN 77 format (the only exception is begin_run, and define_hists where USE statements had to be introduced to allow calls to module subroutines). Code in this directory has the extension .F and is therefore compiled with the f90 compiler as FORTRAN 90 fixed format code. The subdirectory mainf90 contains the E614 main analysis code. For this release, the TDC unpacking, geometry, calibrations, and main histogramming modules reside in this subdirectory. This subdirectory will also contain other software packages once they are developed and tested. In contrast, code that is still under development and testing, as well as utility code that is needed by different users will reside in the user subdirectory. The code in the mainf90 and user subdirectories carries the extension .f90and is therefore compiled with the f90 compiler as FORTRAN 90 free format code. The photosubdirectory includes the code needed for the ROOT package (event display) which is written in C++. The photo directory therefore contains C++ code as well as some FORTRAN subroutines to provide the link between the MOFIA FORTRAN code and the display C++ code. The includesubdirectory includes all the include files, common blocks, parameter files, and interface blocks.}

^{When a module is compiled, the compilation process goes through two steps: first a file with extension .mod is created and then the .obj file is created. The .mod file resides in the modules subdirectory. These .mod files are needed when other modules that USE them are compiled to enforce type checking on all procedure calls. Finally, the subdirectory dummy contains "dummy" modules and subroutines. This serves two purposes. First, for purposes of testing (or convenience) a certain part of the code might not be required. This is achieved by calling the equivalent dummy module/subroutine to replace the actual package. Second, the use of dummy modules provides a way to simplify the compiling and linking process when interdependencies between modules in different subdirectories is present (through USE statements). The dummy subdirectory also contains dummy subroutines for user code such as my_begin_run, my_end_run, my_init, etc. When the user needs to modify these subroutines, they should be copied to the user subdirectory, modified, and added explicitly to the Makefile (in the user subdirectory). The compiler will first look for these files in the user subdirectory, if the specified files are not present, the compiler will find the .obj files in libdummy.aand link with them instead.}