The STAR experiment

This is a study of 2005 data conducted in May 2006.  Ported to Drupal from MIT Athena in October 2007

Hi jetters. Mike asked me to plot the charged track / pion asymmetries in a little more detail. The structure is the same as before; each column is a trigger, and the four rows are pi+/Yellow, pi+/Blue, pi-/Yellow, pi-/Blue. I've split up the high pt pion sample (2< pT < 12 GeV) and plotted single-spin asymmetries for timebins 7,8, and 9 separately versus pT and phi.  The plots and summaries are linked at the bottom of the page.

2 sigma effects are highlighted in yellow, 3 sigma in red. There are no 3 sigma asymmetries in the separate samples, although pi-/B/JP1 is 3 sigma above zero in the combined sample. Here's a table of all effects over 2 sigma:

timebin	charge	trig	asym	effect
8	+	HT1	Y	+2.2
9	+	JP1	B	+2.07
9	-	JP1	B	+2.45
7-9	-	JP1	B	+3.15

If you compare these results with the ones I had posted back in March (First Look at Single-spin Asymmetries), you'll notice the asymmetries have moved around a bit for the combined sample. The dominant effect there was the restriction to the new version of Jim's golden run list. The list I had been using before had at least two runs with spotty timebin info for board 5; see e.g.,

http://www.star.bnl.gov/HyperNews-star/protected/get/jetfinding/355/1/1/1.html

and ensuing discussion. I'm in the process of plotting asymmetries for charged track below 2 GeV in 200 MeV pT bins and will post those results here when I have them.

This is a study of 2005 data conducted in March 2006.  Ported to Drupal from MIT Athena in October 2007

eL_asymmetries.pdf
phi_asymmetries.pdf

+	MB	HT1	HT2	JP1	JP2
Y	0.0691 +/- 0.0775	0.0069 +/- 0.0092	-0.0038 +/- 0.0126	0.0086 +/- 0.0104	0.0116 +/- 0.0069
B	-0.0809 +/- 0.0777	-0.0019 +/- 0.0092	-0.0218 +/- 0.0126	0.0067 +/- 0.0104	-0.0076 +/- 0.0069

-	MB	HT1	HT2	JP1	JP2
Y	-0.0206 +/- 0.0767	-0.0193 +/- 0.0092	-0.0158 +/- 0.0130	-0.0035 +/- 0.0101	0.0061 +/- 0.0070
B	0.0034 +/- 0.0769	-0.0021 +/- 0.0092	0.0006 +/- 0.0130	-0.0164 +/-0.0101	-0.0147 +/- 0.0070

This is a study of 2005 data conducted in March 2006.  Ported to Drupal from MIT Athena in October 2007

Goal: Quantify the relationship between the z-vertex position and the bbc timebin for each event.

Procedure: Plot z-vertex as a function of trigger and bbc timebin. Also, plot distributions of bbc timebins for each run to examine stability. Exclude runs<=6119039 as a result. Fit each vertex distribution with a gaussian and extract mean, sigma.  Plots are linked at the bottom of the page.  See in particular page 8 of run_plots.pdf, which shows the change from 8 bit to 4 bit onlineTimeDifference values.

Timebin 12 had zero counts for each trigger. Summaries of the means and sigmas:

m	4	5	6	7	8	9	10	11	12
mb	101.7	124.1	56.3	22.72	-7.835	-38.89	-80.48	-135.6	-
ht1	81.09	111.8	50.75	16.88	-13.49	-44.57	-89.36	-182.8	-
ht2	79.86	107.2	48.93	15.76	-14.27	-45.17	-89.76	-176.7	-
jp1	101.3	139.3	54.8	17.68	-12.95	-44.05	-92.4	-176	-
jp2	99.49	128.5	51.58	15.77	-14.29	-45.5	-94.1	-192.2	-

 

s	4	5	6	7	8	9	10	11	12
mb	68.85	67.48	40.4	34.26	33.31	35.91	49.32	76.29	-
ht1	68.99	70.9	43.06	34.71	32.49	34.86	47.42	79.98	-
ht2	67.64	70.13	43.06	34.76	32.55	34.98	47.26	78.22	-
jp1	76.49	79.85	45.44	35.6	32.56	35.34	49.69	78.1	-
jp2	76.18	78.01	45.73	35.79	32.87	35.68	49.37	81.21	-

Conclusions: Hank started the timebin lookup table on day 119, so this explains the continuous distributions from earlier runs. In theory one could just use integer division by 32 to get binned results before this date, but it would be good to make sure that no other changes were made; e.g., it looks like the distributions are also tighter before day 119.  Examining the vertex distributions of the different timebins suggests that using timebins {6,7,8,9} corresponds roughly to a 60 cm vertex cut. A given timebin in this range has a resolution of 30-45 cm.

Updated version.

Abstract:

Motivation:  We see a strange band structure in raw ADC vs. softId plots for the BSMD.  To date these plots have been generated by integrating over all triggers.  The idea here is to restrict to minimum-bias triggers to see if some of these bumps around ADC >~ 500 could be due to trigger turn-on curves.

Results:  At first glance, the trigger doesn't seem to be causing much of the bump.  On the left is a projection of raw ADC for BSMDE strips 1-150 using all triggers from 2005 pp data.  On the right is the same plot for MB-only, rebinned to deal with the limited statistics.  The MB plot was generated from a separate runlist with roughly 3x more statistics than the trigger-integrated plot.

Stats aren't great, but I think one can pick out the three bumps at ~500, ~570, and ~610, plus the ending spikes at ~710.  Looks like it's not the trigger.

References: 
2005 BSMD zero-suppressed ADCs
 

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.