To get an account for the Linux machines (both farms), read what steps need to be taken on obtaining a RAL account and fill in the online web form.
First time users should follow the following steps to get going at RAL:
/home/csf/username on NFS.
Most users won't have to do any special setup.
If your RAL CSF account is registered for a different experiment
and bfactory is not your default group
(eg. you are working on both BaBar and CMS), then you should either
bfactory as your default the HEPiX group :csf> mkdir ~/.hepix csf> echo "bfactory" > ~/.hepix/preferred-groupor
if ( -r /usr/local/lib/hepix/central_login.csh ) then source /usr/local/lib/hepix/central_login.csh endif
if ( -r /usr/local/lib/hepix/central_env.csh ) then
source /usr/local/lib/hepix/central_env.csh
endif
/home/csf/usernameTo keep track of the disk space you are using in your home area you can use the command "quota". For example:
[olaiya@csfd]~% quota
Disk quotas for user olaiya (uid 27527):
Filesystem blocks quota limit grace files quota limit grace
csf-home.rl.ac.uk:/home/csf
289444 650000 700000 8607 0 0
csf-varmail.rl.ac.uk:/var/mail
46108 50000 150000 1 0 0
Where the usage, quota and limit numbers have units of kBytes
babar.rl.ac.uk (also known as babar.gridpp.rl.ac.uk).
csfmove01.rl.ac.uk
move03.gridpp.rl.ac.uk
csf.rl.ac.uk, csfa.rl.ac.uk, csfb.rl.ac.uk or csfc.rl.ac.uk as these are not BaBar machines and consequently may not be setup correctly./stage/xrootd-data4-7/). One to serve as a working area (/stage/xrootd-data6/) and the others are for SP.
BaBar users should be aware that the following points apply to disk and data under the /stage/xrootd-dataX
1. The AWG volumes are for business use only 2. The AWG volumes provide a business function 3. There should be no expectation of privacy
Users are able to access their work area in a similar fashion to SLAC, via the path $BFROOT/work/o/olaiya/ for example. This is linked to an NFS disk, so an AFS token is not required. Furthermore it should be noted that neither of these disks are backed up, nor is there any plan to do so. People should start to use their $BFROOT/work/u/user/ area for test release binaries, as they do at SLAC.
newrel -s $BFROOT/work/u/user -t analysis-24 Beta_a24
People should be considerate with their use of disk space in this area. Using large amounts of data will fill up the disk and cause other people's jobs to crash.
Important: So updates to BaBar packages are not scattered between RAL and SLAC, updates are not allowed in the RAL CVS repository. It is locked for writing and you should see warnings if you try to access the RAL repository. Updates must be made directly to SLAC CVS were they will be copied to RAL the following day. To check packages into or update directly from the SLAC repository you can use the command "bcvs". You must have a SLAC AFS token for this to work. Examples of bcvs commands in your release directory:
/nfs/farm/babar/AWG/Tracking/TrkSvtBasedEff --->
/afs/rl.ac.uk/bfactory/AWG/Tracking/TrkSvtBasedEff
/nfs/farm/babar/AWG/PID/pidtables ---> /afs/rl.ac.uk/bfactory/physicstools/pid/pidtables
ssh -h.
If the -k option is listed then your ssh supports token passing.
Otherwise, you can obtain a SLAC token with klog user@slac.stanford.edu,
or the shortcut, kslac. Eg.
csfe ~ > kslac klog adye@slac.stanford.edu Password: csfe ~ > ls /afs/slac.stanford.edu/u/ec/adyeYou can also use your RAL AFS area so your RAL files are easily accessible from elsewhere. Your AFS directory is of the form /afs/rl.ac.uk/user/u/username (eg. /afs/rl.ac.uk/user/a/adye). Note that when you log in you do not obtain an AFS token automatically, so you should use
klog before you try to write there
(by default, read access is universal).
bbrbsub. Jobs can be submitted to the farms from a SL3 frontend by specifying the prod PBS batch queue (this feeds into the sl4p queue).
bbrbsub -q prod -c hh:mm file.job
Also, as the submission queue prod is the default for Linux, omitting the -q option works equally well. Therefore, one can simply submit a job as follows
bbrbsub -c hh:mm file.job
bbrbsub -q express file.job
bbrbsub is a wrapper script for the PBS qsub command. We recommend Babar users use bbrbsub as opposed to qsub as it takes care of a lot of the differences between qsub and bsub. bbrbsub has the following properties:
1. Makes the batch job execute in directory where execution starts
2. Transfers environment variables (with no failure due to character limits)
3. Keeps stdout and stderr on batch node until job ends
4. Enforces use of the prod feeder queue which directs jobs to the sl3p queue
5. Provides a job name of binary/script but limited to 15 letters
6. Allows multiple arguments to be passed to the script on the command line (e.g. bbrbsub -c hh:mm file.job arg1 arg2 arg3 arg4)
bbrbsub uses the same PBS flags as qsub and as with qsub AFS tokens are not passed with the job. However at RAL this is not such a problem as you can use your NFS mounted disk, where an AFS token is not required.It should be noted that bbrbsub does not recognise PBS directives like qsub (i.e commands such as '#PBS -j oe' in the job file). See man page of qsub for details of qsub options that bbrbsub passes straight through.
qdel but also offers the additonal feature of deleting all your jobs in the queue.
bbrbkill (jobnumber) (same as qdel)
bbrbkill 0 (deletes all your jobs)
One additional control (not currently documented there, 24/Jan/06) is the maximum CPU time you specify on your job with the "-l cput=<time>" option.
The maximum amount of time a job can run on a batch machine is 48 realtime hours. This information can be obtained with the command:
qmgr -c "l q sl3p"
Your jobs may start earlier and you might be able to run more at the same time if you make a good estimate of the CPU time they will take (how much of an effect this will be depends on the mix of other jobs in the system). In the long run you will, however, not be penalised by using an estimate that is too long. Also take care not to make the CPU time estimate too tight as a job running above the limit will get killed.
To estimate the CPU time a job requires you can run a test job (with a high limit) and look at the stdout at the end of the batch job. Remember to add a safety margin as the job will be killed prematurely if it runs for too long.
qstat
qstat -u <username>
qstat -q
To look at the output of jobs that are currently running you can use the qcat command
Grid submission for BaBar analysis jobs is still experimental, but is being worked on.
/home/csf), user data disk
(/stage/babar-user1), or AWG data disk (/stage/babar-awgN),
please consider freeing up the space by deleting it -
perhaps after copying it back to your desktop machine or local institution, or
archiving it to tape at RAL.
If these do not get a response then contact Tim Adye or E.Olaiya@rl.ac.uk directly
http://hepunx.rl.ac.uk/BFROOT/csflnx.html last modified
5th Jan 2009 by
Emmanuel Olaiya, <E.Olaiya@rl.ac.uk>
and
Tim Adye, <T.J.Adye@rl.ac.uk>