Linux Hall C Analyzer installation kit
The Hall C analyzer can be run on most reasonably current x86 Linux systems.
While not exaustive, some of the requirements include:
- Redhat Linux 6.1 (x86) with egcs and egcs-g77 installed. Older versions
of Redhat, or other versions of Linux may also work if egcs and
egcs-g77 are installed. The two scripts used to setup the
analyzer do use the rpm command, so will not work
properly with different versions of Linux.
- Lots of memory. 32 MB or more is recommended, 16 will probably
work.
- Lots of disk space.
- Familiarity with building and using the Hall C analyzer on the
JLAB Sun machines. For information on doing this see:
running the Hall C analyzer.
Getting started
Download the file
grover_rh2.tgz.
Pick a
directory to to untar it into. Lets call this directory GROVER. (In
my case, GROVER was ~saw/grover). It is untarred with
mkdir GROVER
cd GROVER
tar -zxf grover_rh2.tgz
System configuration
Before compiling anything, you need to make sure that the Linux
fortran compiler, G77 is installed and that several useful directories
are NFS mounted to your system.
The easiest way to do this is to run the script grovermount.
This will install g77 if it is not installed. It will also setup the
automount daemon so that the following NFS directories are avaiable:
/mnt/Csoft Analyzer source tree (from wood.jlab.org)
/cache SILO cache disk
/apps Computer center Linux applications disk
/site Computer center site specific applications
/u/mirror Mirror of Redhat and other linux ftp sites
To run this script, logon as root and then execute the script
grovermount:
cd whatever/GROVER
./grovermount
This script uses the autofs package to make remote directories
available with the automounter. If you are already running the
automounter, then it will ask if you want to override the
configuration. If you are not sure, say no, study the grovermount
script, and impliment changes by hand.
The grovermount script will also offer to install xntpd, the Network
Time Protocol Daemon. This will keep your Linux machine synchronized
with the correct time and is a good idea.
Setting up the analyzer source tree
The following instructions set up the master source tree (Csoft directory)
against which individual users may build personal analyzers.
- Edit the file GROVER/Groverup. Find the line that starts with
"Csoft_READONLY". Set the definition of the variable to the path of
the directory Csoft that has been NFS mounted above. If necessary,
edit the definition of CERN_ROOT on the next line.
If you have used the grovermount script as is, then these modifcations
will not be necessary.
- Pick an account from which to administer the analyzer software for the
Linux machine. From the root directory of that account source the Csoftup
script:
cd ~
source GROVER/Groverup
Groverup will ask how you want to setup the source tree directory. If
you choose the "local" option, it will copy the analyzer
source tree from /group/hallc/saw/Analyzer. If you choose
the "nfs" option, the source code will be accessed through
NFS, but will still be compiled locally.
Grover will add environment variables
to ~/.bash_profile and also define these variables for the current
logon. These variables are
NFSDIRECTORY The location of the NFS mounted readonly copy
of the analyzer source code. This is only set
if the "nfs" option is chosen above
CERN_ROOT Directory containing CERN bin and lib directories.
Csoft The local copy of the master source and library tree
Groverup also creates the Csoft directory tree with all of the appropriate
makefiles and source code.
- Do the commands
cd $Csoft
make
Setting up a "replay" directory in a user account
Each user that will do analysis on the Linux machine must set up a replay
directory similar to what is set up on HP workstations. The following
procedure may be used.
- Create a replay directory under your HPUX account using the
Oscar procedure.
- Make a tar file of the replay directory made by oscar. For example,
if the replay directory is ~/replay, type
tar -zcf myreplay.tgz ~/replay
- Transfer this tar file to your Linux account.
- From your home directory untar the tar file with, for example,
tar -zxf myreplay.tgz
- Edit or create ~/.bash_profile. Copy from the
.bash_profile made by Groverup the definitions for
CERN_ROOT and Csoft. Also add to this file the
proper definition for ENGINE_CONFIG_FILE. Most likely this
will be
export ENGINE_CONFIG_FILE=~/replay/REPLAY.PARM
- Go to the SRC directory under replay.
- Using the
file Makefile in the GROVER directory, modify the Makefile in
the SRC to be Linux compatible. Your Makefile may already have these
modifications.
- Type make. This should compile a personal analyzer.
- If you get errors in compiling, you may need to update some of the
fortran files in SRC to be compatible with g77. See
the section G77 Compatibility
Issues below.
- Copy some data runs to local disk, edit REPLAY.PARM appropriately
and replay.
Getting data files
The cache disks, which hold data runs that have been retrieved from
the silo can be read-only mounted by any machine at TJNAF. The grovermount script
above should have mounted these cache disks directory under
/cache. The command to request that files be placed in the cache directory must
be run from a CUE machine.
If a data run is to be analyzed several times, it is helpful to
copy it to a local drive.
Other ways of getting data files
Any command that sends a data file to
standard output may be used in the Hall C analyzer to get a run. For example, rsh
might be used if the data file is not in the silo and thus can't be moved to the cache disks.
For example, the
following filename specification will work for recently acuired data on
cdaqh1.
g_data_source_filename = 'rsh cdaqs1 -l yourusername "cat /home/cdaq/coda/runlist/dec97_%d.log"'
For the remote shell command to work, you must list the node name of
your linux machine in the .rhosts file in your home directory
on cdaqh1. This is generally considered not to be a good idea from a
security point of view.
Using compressed files
Saving compressed files on your local disk can increase the amound of
data that you can hold locally. File name secifications like
g_data_source_filename = '|gunzip < nov96_%d.log.gz'
will decompress the data file on the fly. The event reading routines
will actually automatically detect compressed files and decompress them, so
the specification
g_data_source_filename = 'nov96_%d.log.gz'
is sufficient.
Note to users of non Hall C applications:. If you are trying to
apply these techniques of retrieving data to CODA replay applications other
than the Hall C analyzer, you may need to get the
improved version of evio.c.
Some of the fortran code used in the Hall C analyzer is not compatible
with G77. It is possible to modify the code to be compatible with
G77 and remain comptible with the fortran compiler on SunOS. The
main Hall C analyzer source tree is being upgraded with these
changes. (So far, only /group/hallc/saw/Analyzer has had these
modification applied.) So there should be no problems compiling
the source tree in ~/Csoft/Analyzer. However, the source
code from the replay or "Oscarup" directory may not have all these
modifications.
- Format statements
- The blank format code x is sometimes used without a numerical
argument such as:
111 format(i3,x,f10.5,x,f9.5,x,f10.5,x,f9.5,x,f7.3)
In such cases the x should be replaced with 1x:
111 format(i3,1x,f10.5,1x,f9.5,1x,f10.5,1x,f9.5,1x,f7.3)
- Logical comparisons
- G77 has a problem with logical comparisons such as:
if(jiand(CRAW(2),'FFFF'x).eq.'10CC'x) then
This is because left side of the .eq. is an integer type and
the right side is untyped. Lines like this can fixed by
taking the exclusive or (jieor) of the two sides of
the .eq. and comparing the result with zero. For
example, the above line can be replaced with:
if(jieor(jiand(CRAW(2),'FFFF'x),'10CC'x).eq.0) then
- Character string arguments
- If a subroutine has a character string as an argument, the
variable must be declared as a variable width string. If this
is not done, seeming unrelated and difficult to debug errors
will result. So far this has been found to be a problem in
some versions of the routine g_analyze_misc.f where the
declaration:
character*1024 errmsg
must be replaced with:
character*(*) errmsg
- Initializing variables
- According to the Fortran definition, variables must be initialized
before use. Most compilers though set defaults values of zero
or .false. for variables and some of the Analyzer code depends
on that. However, the g77 compiler does not initialize
variables. In particular, this can cause problems with
engine.f as many copies of it don't initialize the
logical variables used to control the event loops. Make sure
that the following lines are near the top of engine.f
ABORT = .false.
problems = .false.
EoF = .false.
finished_extracting = .false.
Last modified: Wed Feb 2 10:45:35 EST 2000
saw@jlab.org