The STAR experiment

The goal of the workshop is to re-examine and assemble the key physics STAR will be addressing over the next eight years in light of the greatly increased DAQ rate capability and increas

Documentation for the beampipe support geometry description development

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.

See http://www.star.bnl.gov/STAR/ssd/pictures/removal2007/