The STAR experiment

Background:  Ahmed posted some studies of the BSMD in Run 7 indicating that the ADC dynamic range is limited.  Pibero and Willie showed a dramatic band structure of the raw ADCs in the 2006 pp, and people wondered how far back this structure existed.  Here is the data from 2005.

What's being plotted:

• 2005 pp data
• BSMDE
• zero-suppressed at (adc-ped) < 1.5*rms
• NOT pedestal-subtracted
• restricted to status==1
• ~4000 files from throughout Run 5
• strip softId on x-axis -- each plot is another 1000 strips

And finally, here's a projection of strips 1-150:

Clearly, the band structure was there as well.

Update:  Renee mentioned that 4500-4600 look a little cleaner than the rest.  Here are projections for 4500-4590 and 4500-4650.  The band structure doesn't disappear, but the slope of the exponential fall-off is steeper so fewer counts end up in the screwy 500+ regime.  Here are the results of fits to the region 100 - 150:

0001-0150:  slope = -0.0105
4500-4650:  slope = -0.0130
4500-4590:  slope = -0.0150

See also:  2005 BSMD zero-suppressed ADCs (minbias triggers)

See attached version 1 of the Analysis Meeting talk

Preliminary analyses of the 2006 data have shown an abnormally large DCA for tracks from a 4-day period following a purge of the TPC on the evening of May 18th.  TPC experts have suggested that a recalculation of the drift velocity measurements using the procedure developed for Run 7 may allow for better reconstruction of these tracks.  Here's my first attempt at the recalculation, using Yuri's codes "out-of-the-box".

Procedure

• Restore st_laser DAQ files from HPSS
• cons StRoot/StLaserAnalysisMaker
• Run a simple BFC chain:  root.exe -q -b 'bfc.C(9999,"LanaDV,ITTF","path_to_st_laser_daq_file")'
  
• execute LoopOverLaserTrees.C+("./st_laser_*.tags.root") to generate drift velocity measurements

StLaserAnalysisMaker has a README which documents this procedure and describes the other macros in the package.

Results

Here are the drift velocity measurements currently in the Calibrations_tpc database and the ones that I recalculated from the st_laser DAQ files.  I'm only showing measurements from the 10 days around the purge:



I'm not sure how much attention should be paid to the original East laser measurements.  The West laser measurements in the DB track pretty closely with the new ones.  The significant difference is that there are more new measurements covering the period where the D.V. was changing rapidly:



So what we're really interested in is, for a given event, how different will the D.V. returned by the database be?  The way to calculate that is to compare each new measurement to the DB measurement with the closest preceding beginTime:



In the West ratio plot one can clearly see the effect of the additional measurements.  For comparison I've plotted the time period where we see problems with the track DCAs and <nTracks> / jet.  See for example

http://deltag5.lns.mit.edu/~kocolosk/protected/drupal/4036/summary/bjp1_sum/bjp1_sum_dcaG.gif

http://drupal.star.bnl.gov/protected/spin/trent/jets/2007/apr06/problem_highlights.gif

http://cyclotron.tamu.edu/star/2006Jets/apr23_2007/driftVelocityProb.list

Next Steps

As I mentioned, I didn't tweak any of the parameters on Yuri's codes to get these numbers, so it may be possible to improve them.  I looked at the sector-by-sector histograms in the file and the values for the drift velocities looked generally stable.  The values for the slopes jumped around a bit more.  Assuming there are no additional laser runs that I missed, we could look into interpolating between drift velocity measurements to get even more fine-grained records of the period when the gas mixture was still stabilizing.  Here's an example of a fit to the new combined drift velocity measurement in the rapidly-varying region:

References

Discussion on starcalib:  http://www.star.bnl.gov/HyperNews-star/get/starcalib/402.html
 

Here's a sample breakdown of the time it takes to initialize each of the databases we use in STAR: I'm a little confused by the fact that StarDb is not equal to the sum of all the other tables, but the breakdown clearly indicates that the SVT tables take up far more time than all the other listed tables combined.  If we could find a way to turn off loading of those tables it would be a great help to people doing code development (and would likely take some load off the DB servers as well).  I understand Yuri is working on something in this department, but I'm not sure how far along it is.

UPDATE

I repeated this test again and found that this time StarDb ~ Calibrations_svt:

MY HACK

After a bit of digging I found that one can skip the SVT tables by adding the following line to the beginning of StDbConfigNodeImpl::buildTree:
I've made this hack available in ~kocolosk/fastDbLib. I can't guarantee it won't have side-effects, but with DB load times reduced to < 1 second I think it's worth a shot.

MY HACK, VERSION 2

I missed some recursion in the first hack; this seems to do a better job:

These plots were generated from the IUCF MuDsts, both /star/institutions/iucf/hew/2006ppLongRuns/ and /star/institutions/iucf/balewski/prodOfficial06_muDst. 

I continue using HIJING and trying to understand the energy-momentum-conservation in d+Au.

  

A schematic view of a cross section is:

Requests #1154003721 and #1154003633 (Upsilon and J/psi into Pythia+pp)