>
1 Mofia 2.0 Implementation Notes
1.1 Fortran 90 Migration Path
We have not significantly changed the code which is largely common
to E787 and deals with event handling, skimming, run control and
I/O assignments, CFM, and YBOS initializations. This is the code found
in the main/ subdirectory. It has had many years of testing and
debugging, so there is little to be gained from changing it.
Procedures that are unique to E614 such as read_det_geom and
begin_run have had USE statments added to give them access to the f90
procedures, and setup_geometry has been rewritten to use the new data
types and moved from main/. The BLOCK DATA routine kdata.F will be
used only for initialization of the common blocks filled in the main
directory-it may be convenient in future to use a module instead for
this purpose so that it can be loaded from a library. The namelists
are also implemented in main and contain both E787 and E614-specific
code. All of this code remains in fixed format with extension .F
Common blocks and parameter definitions are implemented through
include directives using cpp. Many of these are required outside of
main/. The include files have therefore been modified to be
compatible with both fixed and free source formats by removing
continuation lines and using ! to delimit comment lines. For commons
extending over several lines
COMMON /common/ aaa, bbb, ccc
1 ddd,eee,fff
is replaced by the equivalent
COMMON /common/aaa, bbb, ccc
COMMON/common/ ddd, eee, fff
Interface blocks are used to enforce type checking for the
external routines ie main/, ybos/, etc. The required information
for each procedure (procedure name and definitions of the passed
variables) are placed in files procedure.ifb in the include/
directory and included in all routines accessing this procedure.
Please note the caution regarding the interface
bug found on DEC alpha.
The procedures for filling the new geometry data structures and
the tdc hit structures are now implemented in f90 modules in free
source format. The intention is that the new code to be written for
pattern recognition and tracking will be placed in modules and obtain
required globals and procedures from modules. For code in modules
interface blocks are not allowed and type-checking of parameters is
automatic. We have used the suggested style of upper-case keywords
and lower-case variables which is supported by emacs. For better
readibility separate lines are used for each statement.
1.2 Module Coding Rules
We are developing a strategy aimed at data encapsulation to
facilitate program reliability and debugging. The basic concept is to
base modules on groupings of related data objects - the kinds of
things that we would normally group into a common block. Module
components would group together data-type definitions, variable
definitions, variable initializations, procedures accessing these
data types and data structures, and operators defined for these data
types. Some of the data need be accessed only by procedures within
the module, facilitating encapsulation. In some cases it will be more
convenient or efficient to have procedures which operate on data
defined in several different modules and pass them as global
variables through use association. In this case the rule for which
module to place a procedure in will be determined by the hierarchical
nature of use association; if module b uses a, then a cannot use b.
We've also come up with some convenient naming conventions:
- Data type definitions end in _type.
- Module names are root_mod.f90.
- Procedure names within the module will often contain root.
When a module is compiled, two files are produced, with extensions .o
and .mod. The .mod file contains the variable and procedure type
definitions, and is used in the compilation stage of other use
associated modules to enforce type cosistency. These files are all placed
in a separate /module subdirectory, much like include files.
Contents of a typical module are (in order):
- USE statements
List module names containing data or procedures accessed in
this module.
- PRIVATE Make variables inaccessible by default.
- PUBLIC names List of variables and procedures to be made
accessible through use association. If the module contains only
public names and has no USE statements then PRIVATE and PUBLIC can be
omitted.
- IMPLICIT NONE
- TYPE, INTEGER, REAL, INTERFACE
Data type definitions, definitions of variables global to the module, interface blocks.
For consistency between modules the interface block code will be put in a .ifb file
and included by the cpp preprocesser.
- CONTAINS Followed by code for procedures.
1.3 Module dependencies
In constructing Makefiles for f90 programs the interdependency of
modules through USE association is a consideration. This is very
similar to the dependency of f77 routines to changes to their included
files. Morgan Burke has developed for E787 a makedepend script to take
this into account, and we have expanded it to include USE associated
files. Running makedepend.csh in a directory containing .f90 files
creates a Dependencies file specifying all dependency rules. This file
is included in the Makefile to guide the compilations. The ordering of
the modules in the Makefile should have dependent modules following
their dependees.
1.4 GNU/Linux Installation Notes
Installation of Mofia on a GNU/Linux system using the Absoft compiler was considerably more
involved than the installation on the alpha platform. This is not
so much a reflection on the Absoft compiler as a reflection of our
starting point.
With the alpha we started with a version working
with DEC f77, while the Linux version had been compiled with
g77. Unfortunately Absoft and g77 appear to be incompatible
because of conflicts with the f2c library required by
g77. Therefore it was required that all the relevant packages -
YBOS, BRU, CFM, GPLOT and CERNLIB all be compiled with Absoft f90.
Here are some of the required mods:
- No inline comments in #include lines.
- ACTION=READ and FILE= in I/O (instead of DEC READONLY and NAME=)
- POINTER instead of %LOC to get address of variable.
- Use READ(CHARVAR, format) i to convert numbers to char instead of
function calls.
- A dummy subroutine name is needed to force loading of BLOCK DATA
from libraries.
The required libraries (tarred and gziped) for cernlib can be obtained by
ftp from the e614 account on lin01.triumf.ca (usual password
construction) in the directory e614soft_f90/triumf. The cernlib
sources are in a separate file and should not be required. The
other libraries will be available from CVS.
The Absoft code has been compiled using some DEC conventions
rather than default Absoft ones. This is not necessary and perhaps
not desireable but it works. It does require more elaborate
Makefiles on GNU/Linux. These conventions are using the . f90
extension for source files with preprocessor directives (Absoft
standard is .F90) and object files produced with lower case with
underscore for entry names. With these conventions the source
files have the same names on both platforms, and source files needed
by the Absoft xfx debugger are produced.
File translated from TEX by Thttp://hutchinson.belmont.ma.us/tth/">T size="-1">TH, version 1.95.
On 4 Oct 1999, 12:26.