The STAR experiment

Data

Monte Carlo

Instead of producing lots of 2007EmcMbStatus runs to generate pre-production status tables, I thought we should look into using the compressed tower spectra Jan saved in the l2ped monitoring program.  I wrote a script to regenerate histograms from these ASCII lines and then asked Matt Cervantes to run the CSMStatusUtils code on them.  I also asked him to run the status code on standard histograms produced by analyzing MuDsts for a single test run (8141062).  I compiled some stats on the differences between the  offline status and the l2 status:

offline == 1, L2 != 1:  76 towers
offline != 1, L2 == 1:  8 towers
Both bad, but different reasons:  40 towers

Some comments:

• L2 status had trouble catching stuck bits (220, 1143, 1612, 2188) as well as recognizing cold towers (187, 4595).  These two scenarios accounted for pretty much all of the cases where L2 marked a tower good and offline didn't.
• L2 marked a bunch of towers with high pedestals as "cold", since there are zero counts above 60.  Most of the differences in Case 1 are due to this problem.
• Generally very good agreement -- less than 2% of towers were different if all you care about is status==1.

We'd like to tweak things a little to see if we can catch the few differences we have.  In particular, marking all those towers as cold could hurt the vertex-finding efficiency a little bit (that's all we really care about in this pass). 

Detailed status codes and histograms are available at the bottom of the post.

• xgrid.pm can submit and cancel jobs successfully, haven't tested "poll" since the server is running WS-GRAM.
• Xgrid SEG module monitors jobs successfully.  Current version of Xgrid logs directly to /var/log/system.log (only readable by admin group), so there's a permissions issue to resolve there.  My understanding is that the SEG module can run with elevated permissions if needed, but at the moment I'm using ACLs to explicitly allow user "globus" to read the system.log.  Unfortunately the ACLs get reset when the logs are rotated nightly.
• CVS is up-to-date, but I can't promise that all of the Globus packaging stuff actually works.  I ended up installing both Perl module and the C library into my Globus installation by hand.
• Current test environment uses SimpleCA, but I've applied for a server certificate at pki1.doegrids.org as part of the STAR VO.

Important Outstanding Issues

• streaming stdout/stderr and stagingOut files is a little tricky.  Xgrid requires an explicit call to "xgrid -job results", otherwise it  just keeps all job info in the controller DB.  I haven't yet figured out where to inject this system call in the WS-GRAM job life cycle, so I'm asking for help on gram-dev@globus.org.
• Need to decide how to do authentication.  Xgrid offers two options on the extreme ends of the spectrum.  On the one hand we can use a common password for all users, and on the other hand we can use K5 tickets.  Submitting a job using WS-GRAM involves a roundtrip user account -> container account -> user account via sudo, and I don't know how to forward a TGT for the user account through all of that.  I looked around and saw a "pkinit" effort that promised to do passwordless generation of TGTs from grid certs, but it doesn't seem like it's quite ready for primetime.

I am using FTPC hits to study the hit density in the forward region. For this I use files from run 7145009, where the BBC coincidence rates were around 500 kHz.

While I am waiting for my simulation jobs to finish, I am switching gears for a moment and looking at real data.  I am trying to finalize the mass window I use for my asymmetry measurement. 

At the moment my main focus is the off line calibration of the barrel EMC using neutral pions from 2006.  My (very) rough plan of how to do this is as follows:

where

• L_int_mb is the integrated luminosity seen by the minbias trigger for runs in which the specified trigger was active
• eps_vtx is the vertex finding efficiency for this trigger
• eps_mb is the vertex finding efficiency for mb-triggered events in runs in which the specified trigger was active
• vz is the fraction of events with a reco vertex that had fabs(vz) < 60 cm
• vz_mb is the same quantity for mb triggered events
• L_samp_mb is N_good_vertex_mb / (eps_mb * sigmaBBC))
• < ps > is sum_{runs} (ps_mb * n_mb) / sum_{runs} (ps_trig * n_trig)
• L_sampled is L_samp_mb * < ps >

Data were obtained from the 289 spinTree runs without any additional QA selection.  If I restrict to the 188 runs in the latest jet runlist I get

The vertex finding efficiency for minbias triggers climbs a little bit, but it's still only 51%.  After doing a little digging it seems this is consistent with Jan's findings in his evaluation of PPV for 2006:

http://www.star.bnl.gov/HyperNews-star/protected/get/starspin/2820.html

How much of the large-scale variation is coming from the multiplicity and z-vertex averaging?

I wrote a script that compares each Run 7 BTOW pedestal table with a corresponding L2ped printout. The script queries the RunLog_onl database for the runnumber immediately preceding the table timestamp, then it looks for a log file corresponding to that runnumber in the L2ped directory on online.star.bnl.gov. If it can’t find the precise runnumber, it compares the online pedestals to the next closest L2ped runnumbers both before and after, and then prints the comparison for the better match.

Here’s a summary log printing the number of channels per table where

1. the difference in pedestal value is greater than 4, or
2. the difference in pedestal sigma is greater than 1.5

There are a handful of channels per run with drastic differences. For example, emcOnline will declare a zero pedestal, but l2ped will say there’s a peak at 3500 ADCs. Channels like these are obviously bad. Of greater concern are the runnumbers where several hundred channels do not match. Most of the time it’s because the widths are different, but occasionally there are runs where a few hundred towers will have pedestals that differ by more than 4 ADCs. The full verbose output (listing every tower that fails the cut) can be found here.

.