Proposal for defining BaBar environment on LCG sites. V00-00-02

Job Types

There are currently two types of BaBar jobs on the grid. Simulation Production jobs and User Analysis jobs, we should use a common infrastructure for these where ever possible.

Software Installations

The two jobs types currently have completely different software installations. The SP jobs require a cut down SP only installation that can be initiated and checked over the grid using the tools provided. User analysis jobs need to have access to the full BaBar software environment. This could be installed stand alone locally or sharing a release from another site that makes there's available over some WAN protocol like AFS. At present a procedure for installing the full BaBar framework inside the LCG framework has not been developed. This plan is concerned with making a pre-existing installation that is visible to the LCG WNs usable by BaBar jobs.

Most LCG sites supply supported VOs with an area mounted on all the worker nodes where they can install experiment specific software. For BaBar this area is always located with the Environment Variable $VO_BABAR_SW_DIR. Scripts for setting up the BaBar environment will be installed in a bin directory under this well known location.

Job Initialisation - User Jobs

When a job starts the only BaBar specific environment it receives is the $VO_BABAR_SW_DIR, we must provide the rest. For user analysis jobs a three set process similar to interactive jobs is proposed. User jobs should perform some or all of the following steps as required.
  1. (.|source) $VO_BABAR_SW_DIR/bin/babar-grid-env-setup.(c)sh This replaces in a very simple form the BaBar login scripts. It would: This script may also set up other site specific things. For instance sites wishing to use the RAL AFS BFROOT remotely need to provide a local path to the Objectivity libraries and define the following variables:
  2. (.|source) SRTStartUp.(c)sh Release If the user is shipping/building a release directory on the WN this should complete the setup. User jobs should specify the required release as no assumptions about the value of current can be made
  3. (.|source) condXXboot.(c)sh
    4. Sets OO_FD_BOOT to the local objyserver/boot file and any other local objectivity specific variables (OO_AMS_USAGE, OO_AMS_HOST, etc.)

Data Location - KanAccess.cfg

SP jobs and jobs at sites with their own BaBar software installation pick up the KanAccess.cfg file from the usual location, either in $BFROOT/kanga/KanAccess.cfg or from the reduced release. For sites with a shared software installation wishing to override the default KanAccess.cfg should place the replacement in $VO_BABAR_SW_DIR/kanga. The babar-grid-env-setup script will copy or link it to the working directory of the job before starting the BaBar application. If the job changes working dir or wants to override the default it copy or replace the file accordingly.

Site Tagging

BaBar can tag sites with strings which can then be used to direct jobs to sites that can support them. We proposed the following initial set of tags:
VO-babar-user
Site has the general environment for BaBar user jobs i.e. the babar-grid-env-setup.(c)sh scripts and what they setup.
VO-babar-site-{BFSITE} (VO-babar-site-ral)
Babar "site" tag to allow linking of the generation of tcl and the selection of the site
VO-babar-release-{xx.yy.zzl|analysis-nn}-{BFARCH} (VO-Babar-release-16.0.5-Linux24SL3_i386_gcc323) or VO-babar-release-analysis-23-Linux24SL3_i386_gcc323)
Site has BaBar release xx.yy.zzl or analysis-nn available for use by user grid jobs. implies that condxxboot is also available for that release.
VO-babar-sp-release-{xx.yy.zzl}-{BFARCH} (VO-babar-sp-release-18.0.4d-Linux24SL3_i386_gcc323)
Site has reduced SP Moose installation of that relase
VO-babar-sp-valid-release-{xx.yy.zzl}-{BFARCH} (VO-babar-sp-valid-release-18.0.4d-Linux24SL3_i386_gcc323)
Release xx.yy.zzl has been validated for SP production at site
VO-babar-sp-cdb-SPn-XXXXXX VO-babar-sp-cdb-SP8-eighth
Conditions database for simulation production round "n" with default view SPn::XXXXX is available at the site
VO-babar-skim-{XXXXX} (VO-babar-skim-BFourHHPP)
Skim XXXXX is available via the KanAccess.cfg file.
VO-babar-skim-part-{XXXXX} (VO-babar-skim-part-BPi0Pi0C03a3body)
Part of skim XXXXX is available via the KanAccess.cfg file, users should use the book keeping to craft tcl files specific to this site.

Simulation Production Only Sites

Sites which will only be running simulation production using the packaged Moose only tarball installations need only implement the following subset of the above:

Job Initialisation

The current SP jobs carry their own environment with them and can set up the reduced SP releases. The only extra local information needed is the CondDB setup. $VO_BABAR_SW_DIR/bin/spXboot.(c)sh should be provided to be sourced to do this.

Background Trigger Collection Location

The default KanAccess.cfg file needs to be set up when installing the Moose tarball on a site. This could be done manually by the person installing the software but to make this simpler $VO_BABAR_SW_DIR/kanga/KanAccess.cfg should be created to be copied into the distribution.

Site Tags

The following site tags are used by Simulation Production:

Last modified: Wed Jul 27 17:44:48 BST 2005