Building the Analyzer and BigBite libs from CVS (d2n)

From Hall A Wiki
Revision as of 11:39, 4 September 2009 by Posik (Talk | contribs) (Some Miscellaneous config instructions)

Jump to: navigation, search

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
 % chmod a+x pull_cvs
  • 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 file. You should update the 'd2n' path at least. 'd2n' needs to point to the directory that you called ./pull_cvs from (ie. which contains the 'analyzer/' and 'd2n/' directories.
 % cp d2n/ .
 % vim
 Note: 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 PATH="$ROOTSYS/bin:$PATH"
   use root
   use gcc
  • Source the file to set the environment variables
 % source
  • 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
 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 '' 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.

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
 '' 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