Workbook for BaBar Offline Users - Installing BaBar Software at a
New Site
The installation of the BaBar software can be fairly complex due to
the many dependencies and the small differences at each new site. The
list below is an attempt at a full description of the installation
procedure.
Contents
Software requirements
BaBar currently supports only Scientific Linux 3.0.3 on
Intel x86-compatible processors, and Solaris 8 and Solaris 9 on Sun
Sparc processors.
Hardware requirements
The following minimum requirements are based on RAL experience. These
minimum requirements allowed running of BaBar software in an efficient
way.
CPU |
A machine with a SpecInt(95) above 12 seems sufficient. |
| Memory |
To link the BaBar code consumes large amounts of memory. A
minimum requirement is 350Mb of real memory and 1Gb of virtual
memory. |
| Disk space (BaBar) |
One release of BaBar offline software fills at the moment
about 2GB.
In addition space is required for
storage of personal Objectivity databases. |
| Disk space (users) |
A typical user will use a few hundred Mb for storing
binaries. Those should be accessibly on a fast disk. Space for
storing private Objectivity federations is also required. |
Apart from licences for the compilers and afs which are not
specifically related to BaBar, licences are required for the use of
Objectivity. Do not
proceed with the installation before these licence issues are solved.
SLAC has already obtained an Objectivity license that can be used by
all BaBar collaborators. This includes domestic and international use
within the experiment. However, collaborators may not use Objectivity
for any other purpose but the Babar project. Each collaborator must
sign the license agreement before using the software. For details,
see the
Objectivity Letter to the Collaboration.
It seems wise to keep a directory structure as at SLAC. In this
structure everything BaBar-specific is stored below the directory
pointed to by the environment variable BFROOT.
| Environment variable |
Typical value |
Contains |
BFROOT |
|
The top of the BaBar directory tree. |
| |
$BFROOT/bin |
Scripts common to all releases. Can be left empty. |
| |
$BFROOT/bin.<arch> |
Binaries for specific architecture common to all
releases. The BaBar version of CVS is typically installed here. |
| |
$BFROOT/man |
Manual pages. |
| |
$BFROOT/package |
3rd party software specific to BaBar like
Objectivity. |
BFOVERRRIDE |
$BFROOT/etc |
Local overrides for the position of libraries etc. |
BFDIST |
$BFROOT/dist |
The software releases. |
| |
$BFDIST/packages |
The checked out source code for the installed releases. |
| |
$BFDIST/releases |
The libraries and binaries for the installed releases. |
There is a long list of fairly standard packages required for the
BaBar software to run.
Most are probably available already but a few might need to be changed
to different versions. Be aware that Tcl7.4 is required for the BaBar
releases in the 6.X.X series and that gmake 3.77 has a bug which
breaks the BaBar makefiles. To interact with the CVS repository at
SLAC it is also required to install the SLAC-specific version of
CVS.
BaBar requires CERNLIB version CERNLIB 2002, which can be downloaded
from cernlib.web.cern.ch.
If you wish to install ROOT it can
be picked up from the ROOT distribution
site at CERN.
The relevant files and an instruction on how to install Objectivity
can be picked up from
/afs/slac.stanford.edu/g/babar/package/objy5/Objectivity_admin/Objectivity_src
. Access to this directory is limited in the same way as the
use of Objectivity. The installation process requires
root privileges.
To use the BaBar database you need to run locally both a lock server
and an AMS server.
The lock server can run on any machine at your
site where objectivity is available. Typically it will run on one
of the machines where you perform your analysis. The disk where the
databases are stored should either be local or be NFS mounted on the
machine running the lock server.
There should be an AMS server running on each machine
where there is a local disk used for storing databases. If the
databases are stored on a local (and not just NFS mounted) disk of the
machine where the analysis is performed, there is no need to run an
AMS server.

The lock server and AMS server should be started at boot time of the
machine. On a Sun the script ooserver given below can be
installed in the directory /etc/init.d.
#!/bin/sh
#
# oolocksrc: script to start Objectivity daemons
#
# It has links:
# ln -s ../init.d/ooserver /sbin/rc0.d/K63oosrv
# ln -s ../init.d/ooserver /sbin/rc3.d/S97oosrv
# Need the commands ps, awk, kill
PATH=${PATH}${PATH:+:}/sbin:/bin:/usr/bin
OBJECT=/usr/local/objy5/solaris4
case $1 in
'start')
#
# Start the Objectivity lock server process if binary exists
#
if [ -x $OBJECT/bin/oolockserver ]; then
echo "Starting Objectivity lock server"
su bfactory -c $OBJECT/bin/oolockserver
else
echo "Objectivity lock server not found, exiting"
exit 1
fi
#
# Start the Objectivity AMS server process if binary exists
#
if [ -x $OBJECT/bin/oostartams ]; then
echo "Starting Objectivity AMS server"
su bfactory -c $OBJECT/bin/oostartams
else
echo "Objectivity AMS server not found, exiting"
exit 1
fi
echo ;;
'stop')
#
# Stop the Objectivity lock and AMS server processes
$OBJECT/bin/ookillls
$OBJECT/bin/oostopams
echo ;;
*) echo "Invalid option supplied to $0"
exit 1;;
esac
The user name which runs the lock server and AMS server has to be a
user which belongs to the same NFS group as the BaBar
users. Never run the servers as root.
A release can either be copied from RAL or directly from SLAC in case
it is not present at RAL. If you have a fast network connection to either site, a release can be imported in about 6 hours or more.
To copy a release from RAL define the environment variables:
BFDIST |
The directory where the releases will be stored
as given above. |
BFDISTr |
/afs/rl.ac.uk/bfactory/dist |
Two commands are used to install a release. The first command
importrel installs everything in a release which is not
architecture-dependent. The second command importarch
installs the libraries and binaries for a specific architecture. There
are manual pages available for these commands.
For the very first installation these commands will not be available
locally so they can be picked up by adding a directory at RAL to the
path. An example (in ksh) is given below:
klog -cell rl.ac.uk
export PATH=$PATH:/afs/rl.ac.uk/bfactory/dist/releases/current/bin/Linux24SL3_i386_gcc2953
export BFDIST=...
export BFDISTr=/afs/rl.ac.uk/bfactory/dist
importrel -pa <release name>
importarch -px <release name> <architecture>
The last two commands might take a few hours to complete. At the moment only Linux libraries are installed at RAL (there are no Solaris machines available). If there is a request for Alpha libraries, they
can be installed as well.
At each site some customisation needs to be done to tell about the
differences to the standard SLAC setup.
The login scripts should be executed by every BaBar user at login
time. If the
Hepix login scripts are used this can be set-up as a special group
login file which reads group_sys.conf.(c)sh . If Hepix
is not installed this script should be sourced from the users login
file.
The login files used at RAL can be found in the directory
/home/csf/bfactory/profiles .
As is very well explained in the document
Site Configuration the changes to the BaBar makefiles can be done
in two different ways.
At RAL this is done it through version specific
arch_spec_XX+ files in the $BFOVERRIDE
directory. This is not the ideal way of doing it but allows for
changes to be inserted in retrospect. To look in the
/afs/rl.ac.uk/bfactory/etc/<release>/SoftRelTools
directory at RAL is probably the best way to see how this is done.
A few places in the BaBar code an absolute afs path starting with
/afs/slac.stanford.edu is used for reading data and
configuration files. This can lead to very long startup times of
analysis programs.
There is no automatic way to force the code to read these files
locally instead. At RAL we have copied the configuration files into
the directory /afs/rl.ac.uk/bfactory/reco/datafiles and
have appended some RAL specific lines to
BetaUser/Pathches.tcl. This file can be found as
/afs/rl.ac.uk/bfactory/etc/<release>/BetaUser/Patches.tcl
for each release at RAL.
A full copy of the CVS repository at SLAC is kept at RAL and updated
each night. It can be used by setting CVSROOT to
/afs/rl.ac.uk/repo in the login scripts. It should
however be remembered that there is no copying from RAL to SLAC so the
RAL repository should be used only for checking out files and never
for committing changes. If you want to commit any files they should be committed directly to the SLAC CVS repository where they will be picked up at RAL the following day. For more info you can look at this page
Things that can be easily checked include:
- The
newrel command to check
if the interaction with the CVS repository works. You no longer need a
token for the RAL afs cell.
- A
gmake spec command in
the release directory to check all environment variables.
- The interaction with Objectivity. Check the standard output of
gmake database.import against the
same command issued at RAL or SLAC.
- Try to compile and link a BetaMiniUser job (see Workbook:
Quicktour for
instructions). Keep an eye on the machine during this to see that it
does not run out of memory or some other resources.
If the installation doesn't work first check that everything is
installed as described. If yes there might be several system
parameters on the system that needs to be changed. During the
installation of the Sun service at RAL the standard setup as provided
by Sun was used with the following changes.
- More memory was installed to get 384 Mb in total.
- Swap space was expanded to 1 Gb.
- Tweak Kernel parameter. Set priority_paging=1 to attempt to
prevent process being paged out by disk I/O.
- Downgrade (sic) AFS to AFS34a.6.
- Switch to larger AFS cache and LARGE cache manager configuration.
There is no easy way to update the BaBar software at a remote site (or
I have not discovered it). To import a new release is relatively easy
but it is more difficult to assure there are no new requirements on
compilers, etc.
General Related documents:
Author:
Ulrik Egede
Page maintained by:
Jenny Williams
Last modification: 18 July 2005
Last significant update: 8 May 2003
|