The STAR experiment

Update 2007-07-19

StGammaEvent libraries are also available through this same project.  After building all targets you can do

or just load StarSpinAnalyses, which will load StGammaEvent on-the-fly.  Everything not ending in "Maker" should be accessible, i.e. StGammaCandidates, StGammaFitterResults, etc.

---

One of the goals of the common Spin PWG analysis trees was that they should be readable without the full STAR framework.  The trees are certainly accessible in a plain interactive session, but some of the features are only really available if the class definitions have been loaded.  This page shows how to build those class libraries on a Mac with only ROOT installed.  Here's what we're going to do:

1. Check out the Xcode project.  See SVN Repository Access if you don't have a Subversion client installed
2. Set up the installation directory for the dynamic libraries and tell ROOT to look there
3. Build the dynamic libraries and install them
4. Test it out
   

The code for the first three steps is just


Then you can test it out by opening a ROOT session and doing

What's Included?

You've just installed four dynamic libraries in /usr/local/lib/star.  The StarClassLibrary and StMiniMcEvent targets build exact copies of the respective libraries from the StRoot framework.  StarSpinAnalyses includes

• StJetSkimEvent
• StJet
• StChargedPionTrack
• TPi0Candidate
• StSpinTreeReader
• FastAsymmetryMaker
• StTamuRelLum

In other words, everything needed to read the current version of the common Spin PWG trees.  The StJets library includes the StJets and TrackToJetIndex class definitions.  You'll need it to read the raw jet trees.  Note that the StJetReader class is not yet included (planned for the future when I get a moment).

These libraries are installed and ready to use on deltag5, provided you modify your .rootrc to look in /usr/local/lib/star (setup.sh does this for you automatically if you're building from scratch).  Mike Betancourt was my lone beta tester and while we worked out a handful of glitches, I imagine there are use cases I haven't thought of yet.  In particular, the Xcode project assumes ROOT is installed in /sw. You'll need to edit some Project-level settings if that's not the case.  Feel free to contact me if you run into any problems.

We set up a Subversion repository at MIT to track a few pieces of software that many of us are using, but that don't fit into the STAR framework.

Browsing and Checking Out Code

http://deltag5.lns.mit.edu/viewvc/

will allow you to browse the contents of the repository.  You'll need to have a Subversion client installed in order to check out code.  Simplest way on a Mac is to do

fink install svn-client

although there are also binary .pkg installers floating around for most eveery platform if you'd prefer to go that route.  Then do

svn co http://deltag5.lns.mit.edu:8080/svn/modulename

Committing Changes

The web server doesn't do any authentication, so if you plan on committing changes to these packages you'll need to be added to the svnusers group on deltag5 and you'll also need to use ssh to get your working copy:

svn co svn+ssh://deltag5.lns.mit.edu/svnrep/modulename

In that case, make sure that your .bashrc on deltag5 adds /usr/local/bin to your $PATH.  Note that this method may ask you for your password as much as 4 times, so publickey authentication is your friend (see SSHKeychain for Macs).

For more information on Subversion (basically the successor to CVS) take a look at http://svnbook.red-bean.com/

In the 2003+2004 jet cross section and A_LL paper we quoted a 5% systematic uncertainty on the absolute BTOW calibration.  For the 2005 jet A_LL paper there is some interest in reducing the size of this systematic.

I went back to the electron ntuple used to set the absolute gains and started making some additional plots.  Here's an investigation of E_{tower} / p_{track} versus track momentum.  I only included tracks passing directly through the center of the tower (R<0.003) where the correction from shower leakage is effectively zero.

Full set of electron cuts (overall momentum acceptance 1.5 < p < 20.):

dedx>3.5 && dedx<4.5 && status==1 && np>25 && adc>2*rms && r<0.003 && id<2401

I forgot to impose a vertex constraint on these posted plots, but when I did require |vz| < 30 the central values didn't really move at all.




Here are the individual slices in track momentum used to obtain the points on that plot:







Electrons with momentum up to 20 GeV were accepted in the original sample, but there are only ~300 of them above 6 GeV and the distribution is actually rather ugly.  Integrating over the full momentum range yields a E/p measurement of 0.9978 +- 0.0023, but as you can see the contributions from invididual momentum slices scatter around 1.0 by as much as 4.5%

Next Steps?  -- I'm thinking of slicing versus eta and maybe R (distance from center of tower).

I ran a couple of TStopwatch tests on the Run 5 common trees.  Here are the specs:

Hardware:  Core Duo laptop, 2.16 Ghz

Trees:  805 runs, 26.2M events, 4.4 GB on disk

Languages:  CINT, Python, compliled C++

I also tested the impact of using a TEventList to select the ~11M JP1 and JP2 events needed to plot deta and dphi for pions and jets.  Here's a table of the results.  The times listed are CPU seconds and real seconds:

	Chain init  + TEventList generation	Process TEventList
CINT	156 / 247	1664 / 1909
Python	156 / 257	1255 / 1565
Compiled C++	154 / 249	877 / 1209

I tried the Python code without using a TEventList.  The chain initialization dropped down to 50/70 seconds, but reading in all 26M events took me 1889/2183 seconds.  In the end the TEventList was definitely worth it, even though it took 3 minutes to construct one.

Conclusions:

1. Use a TEventList.  My selection criteria weren't very restrictive (event fired JP1 or JP2), but I cut my processing time by > 30%.
2. I had already compiled the dictionaries for the various classes and the reader in every case, but this small macro still got a strong performance boost from compilation.  I was surprised to see that the Python code was closer to compiled in performance than CINT.
   

Notes on embedding test sets for CuCu, P06ib. I ran several sets of embedding test files at PDSF, named Piminus_00x_spectra.

Set Number

Field

Notes

QA