Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Workbook Home Introduction Account Setup QuickTour Packages Modules Unwrap page!
Event Information Tcl Commands Editing Compile and Link Run the Job Debugging
Check this page with the
W3C Validator
(More checks...)
Parameters Tcl Files Find Data Batch Analysis ROOT Tutorial

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.


Before Starting

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.

Directory structure

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.

Installing Third Party Packages

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

If you wish to install ROOT it can be picked up from the ROOT distribution site at CERN.

Installing Objectivity

The relevant files and an instruction on how to install Objectivity can be picked up from
/afs/ . 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.

Always have the
AMS server running on the machine with the local disk for the

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.

# 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

case $1 in

# 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 
	echo "Objectivity lock server not found, exiting"
	exit 1

# 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 
	echo "Objectivity AMS server not found, exiting"
	exit 1

echo ;;


# Stop the Objectivity lock and AMS server processes


echo ;;

*) 	echo "Invalid option supplied to $0"
	exit 1;;

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.

Copying a Release

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/
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
export PATH=$PATH:/afs/

export BFDIST=...
export BFDISTr=/afs/

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.

Site Customization

At each site some customisation needs to be done to tell about the differences to the standard SLAC setup.

Login scripts

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 .

Makefile overrides

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/<release>/SoftRelTools directory at RAL is probably the best way to see how this is done.

Data files

A few places in the BaBar code an absolute afs path starting with /afs/ 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/ and have appended some RAL specific lines to BetaUser/Pathches.tcl. This file can be found as /afs/<release>/BetaUser/Patches.tcl for each release at RAL.

CVS Repository

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/ 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:

System management issues

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.

Keeping Updated

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:

Back to Workbook Front Page

Send comments to Workbook Team.