Difference between revisions of "Building the Analyzer and BigBite libs from CVS (d2n)"

Latest revision as of 11:47, 8 December 2010

If you are running on d2n.jlab.org

Then you should be using the common analyzer package installed in '/usr/local/d2n_analysis/'. Set yourself up by following these instructions.

• Make a copy of the updated replay directory:

   % cp -a /usr/local/d2n_analysis/d2n-replay <your_path>

• Be sure to update the symlinks to your ROOTfiles dir, for example:

   % cd d2n-replay/replay
   % rm localROOT
   % ln -s /data1/${USER} localROOT

• Update your environment variables using the new template

   % source /usr/local/d2n_analysis/root-setup.sh

• Now your config will be using:
  • the analyzer in /usr/local/d2n_analysis/analayzer/
  • the DB files in /usr/local/d2n_analysis/d2n/DB/

Please read the README and CHANGELOG in /usr/local/d2n_analysis/d2n/ for more details and some suggestions about running parallel jobs.

If you are not running on d2n.jlab.org

• You probably should be. Talk to Brad about an account.

Here's how I set-up an analyzer on my Debian 'Lenny' distribution

 I use bash and vim like all right-minded people :-p
 The Transversity wiki also has lots of good info:
 Off Line Analysis for transversity

• Install ROOT (if you haven't already)

 % apt-get install root-system

• Download and build the analyzer and the d2n replay code

 % mkdir d2n_analysis
 % cd d2n_analysis
 % wget -nd http://www.jlab.org/~brads/hacks/pull_cvs
 % chmod a+x pull_cvs
 NOTE:  The 'pull_cvs' script has been updated to get the analyzer branch from a tarball.  (08 Dec 2010)

• This script sets the appropriate CVS variables and pulls the d2n/ and analyzer/ branches

 % ./pull_cvs

• You should now have two new directories

 % ls -F
 analyzer/  d2n/  pull_cvs*

• Copy and edit the root-setup.sh file. You should update the 'd2n_root' path at minimum. 'd2n_root' needs to point to the directory that you called ./pull_cvs from (ie. which contains the 'analyzer/' and 'd2n/' directories.

 % cp d2n/root-setup.sh .
 % vim root-setup.sh

 NOTE:  'root-setup.sh' has been updated to do the following automatically.  You should only have to update the d2n_root path.
 (Obsolete): If you're building on a JLab CUE system, replace these lines
   export ROOTSYS="/usr"
   export SHLIB_PATH="$ROOTSYS/lib"
   export LD_LIBRARY_PATH="$d2n/:$HOME/lib:$LD_LIBRARY_PATH"
   export LD_LIBRARY_PATH="$ROOTSYS/lib:$LD_LIBRARY_PATH"
   export PATH="$ROOTSYS/bin:$PATH"
 with
   use root
   use gcc

• Source the file to set the environment variables

 % source root-setup.sh

• Build the base analyzer

 % (cd analyzer && make)

• Build the BigBite and replay code

 % (cd d2n && ./makeall)

• Now move into the default replay directory

 % cd d2n/replay/

• Set up symlinks

 The following directories should all be replaced with symlinks
   summaryfiles/
   ScratchROOTfiles/
   ROOTfiles/
 that all point to an appropriate work disk that is NOT in your $HOME
 directory.  (Your sys-admin and backup software will thank you for it.)

• Now you should be able to run the analyzer as you normally would

NOTE:  The environment variables in 'root-setup.sh' need to be
       set properly or the analyzer will not work.  I put the
       script in $HOME/bin and then source it in my .bashrc.

Updating your code from CVS

• Set some environment variables to point to the right system/path. I also set up an alias for cvs so I don't have to type in the root directory argument every time.

 echo "Setting up CVS..."
 export CVSROOT=cvs.jlab.org:/group/halla/analysis/cvs
 alias cvs="/usr/bin/cvs -d $CVSROOT"

• • Check to see what has changed

 This will recursively list changes starting in your current working directory.
 cvs diff

• • Update your tree:

 This will recursively pull updates from CVS changes starting in your current working directory.
 cvs update -P

• • Update a file:

 cvs update -P <file>

Some Miscellaneous config instructions

• Configure env variables to point to ROOT, etc

 If you're not on a JLab CUE system, you may need to edit and source the the
 'root-setup.sh' file.  The settings in the file work for my debian 'lenny'
 distribution.  YMMV.

• • If you're setting up the analyzer on the work disk, the one environment variable you need to change is

 % export ROOTSYS="/apps/root/PRO/root/"

• Problem building the BigBite specific libraries in the transversity/ branch

 If you see a 'atoi' undefined error when compiling bigbitelib then add the
 following line to the include list in 'BBDecData.cxx' and recompile.
 #include <stdlib.h>
 This fix is in the 'd2n' CVS branch.  (22 June 2009, BDS)

• Problems replaying Bigbite data files

 If you try to replay a Bigbite data file and see the warning <THaBPM::"urb.BPMA"::Decode()>: Number of fired Channels out of range
 Warning in <THaRaster::"rb.Raster"::Decode()>: Number of fired Channels out of range.
 You can fix this by opening the Bigbite replay_det_BB.C script and having the classes THaRasteredBeam and THaUnRasteredBeam use objects BBrb and BBurb
 which have the correct hardware set up defined in the DB directory.

What to do to upload changes to the CVS

Step 0: Try and split your patches into logical chunks

• For example, send one patch that only updates the pion rejector files, then a second patch that updates the Cerenkov files. (Rather than one big patch that changes a whole bunch of unrelated stuff all in one go.)
  • This makes it much easier for others to test the patch and, if there's a problem, roll it back.
  • It also reduces the likelihood that a given patch will conflict with someone else's work. (And makes it easier to merge the multiple changes if there is a conflict.)

Step 1: Integrate your 'test' files into the standard analyzer structure

• For example, for changes to the database ($DB_DIR/*):

1. Start with a clean CVS version of the analyzer and install your updated *.dat files to the correct time-stamped directories in $DB_DIR/. It is critically important that you test any updates going to CVS using a fresh analyzer package that has been minimally modified by your personal config (*especially* test *.dat DB files in the analyzer directory that would take precedence over the ones in $DB_DIR.)
2. Now replay enough runs using that analyzer to make sure it is automatically finding the correct, updated, DB file for any given d2n run period (ie. using the time-stamp keys). Collaborators should be able to pull the CVS copy and be confident that it will work as expected -- it's up to you to make sure your changes function before pushing them upstream.
3. Note that you will likely be pulling the CVS version yourself weeks or months down the line to get updates/fixes applied by others. You don't want to worry about re-applying your own older fixes and updates either.

Step 2: Send Brad your updated files

• If it's a few files, you can just email them with an indication of what files they are replacing (full path please).

• If it's a whole bunch of changes, then you can generate a diff and send that:

 % cvs diff -u [files and/or directory...] > $HOME/analyzer.patch

• • For example, if you have a bunch of updates scattered across the 'd2n/DB/' directory try this:

 % cd d2n
 % cvs diff -u DB > $HOME/analyzer_db.patch

• Check out Transversity:CVS Help, or ask Brad if you have problems