Building the Analyzer and BigBite libs from CVS (d2n)
From Hall A Wiki
Revision as of 15:51, 22 July 2009 by Dseymour (Talk | contribs) (→Some Miscellaneous config instructions)
Contents
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
- 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' 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/root-setup.sh . % vim setup.sh
- 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.
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)
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/*):
- 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.)
- 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.
- 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