In Offline QA at the moment, we restrict QA of tracks to those evens whose highest-ranked primary vertex passes two criteria:

1. rank > 0
2. % of daughters matched to BEMC greater than 20%

This seems to be failing at high luminosity such that almost no primary vertices match these criteria. There are plenty of found vertices, but they fail the second restriction. Here is the distribution of "MinBias" events without a primary vertex ("missed"), with but failing the criteria ("questionable"), and with and passing the criteria ("good") from run 12096047:

I looked at a few event.root files, mostly from fill 15408 (runs 12096030-12097022) and obtained the number of primary vertex daughters and the number of those matched to the BEMC as they are recorded in StEvent and read by StEventQAMaker. They are plotted here vs. <BBC coincidence rate> for the run, with error bars representing the spread (small crossing error bars indicate error on the mean if it's beyond the size of the marker). Blue are total number of daughters of the highest ranked primary vertex, red is for the number matched to the BEMC, and black is the ratio, with a green line indicating 20%:

Hard to say from these statics, but the number of matched daughters shows the most variance, and it looks less like a smooth luminosity effect than a step function, with possible steps between 2.2-2.4 MHz and between 2.8-3.1 MHz. Step functions would correlate more with trigger prescale changes (which change with luminosity but hold constant during each DAQ run) than, for example, SpaceCharge effects in the TPC. But this data isn't sufficient to rule out the latter.

_____________

Justin Stevens noted that there are lines in the production logs that look like this:

StiMaker:INFO  - BemcHitList: nActive=4731 nFired=24 nTrack=192 nMatch=3

So I looked more closely at two runs: the highest luminosity run in fill 15408 (run 12096056, bbcx=3.18 MHz) vs. the lowest luminosity in the same fill (run 12097022, bbcx=1.98 MHz). Here are the distributions of nFired, nTrack, and nMatch (nActive is always 4731 for this data):

So nFired looks the same, but nTrack and nMatch are much higher at low luminosity. I double checked that I got the right numbers from the right files. I guess I'm not sure what these number mean exactly, and of course the trigger mix can play into this somehow...

_____________

Jan Balewski writes:

nActive : # of not masked towers
nFired : # of those with ADC > 8
nTrack : # global tracks passing some QA criteria, including crossing the barrel
nMatch : # of those tracks which cross fired towers

That nMatch is substantially higher in the low luminosity data agrees the earlier observation. The primary vertex daughters were slightly higher at low luminosity too, but not by the factor of x2 that nTrack changes in these plots (more like x1.4).

_____________

2011-04-08: Update with more data:

I processed the first 20 events from all FastOffline event.root files on disk from days 095-098 as of Friday evening and remade my earlier plot:

Now it looks even more like a step function at 2.6 MHz and perhaps again at 3.0 MHz. It does not look like a gradual drop in BEMC matches as would be expected from a TPC SpaceCharge calibration error (the percentage missed would grow smoothly with luminosity and would not "step").

The appearance here is a trigger-change-with-luminosity effect. But I still don't know what change would give these symptoms.

_____________

2011-04-10: Update restricting to VPDMB triggers and looking at signed DCA

Looks like the drop in BEMC matches is pretty smooth within the minbias triggers (though I've had to widen the bins to handle the drop in statistics), and there's hardly any change in the number of primary vertex daughters.

This brings up the question: if TPC SpaceCharge is to blame, isn't matching to the primary vertex more sensitive (smaller window) than BEMC matching?

To assess TPC SpaceCharge, I looked at BBCx and <sDCA> vs. time (approximated by run number - 1200000 + run%1000) to see if the DCAs were getting bad at high luminosity. These plots are made without restrictions on the trigger.

It does look bad for the signed DCAs: the mean approaches -2.5 cm or more, and 3 cm is necessary to associate a track with a primary vertex. It should be remembered that pile-up cuts are not tuned for this data, so it isn't as simple as saying that <sDCA> of triggered event tracks is this bad and a closer look at the histograms used to make this signed DCA determination is warranted. Here are plots of the signed DCA vs. phi from a low luminosity run (12095063) and a high luminosity group (12096059-12096062):

There is no significant pile-up background in these plots, so the <sDCA> shown in the previous plot is a valid quantity and there appear to be two clear issues: TPC SpaceCharge distortion corrections are incorrect, and the BeamLine is off by a few mm! (I confirmed that the east and west DCAs show the sine wave in phase with each other, so it is indeed the BeamLine and not TPC twist.)

I'm still not sure why the number of primary vertex daughters does not appear to drop significantly with luminosity. The only thing I can think of is that pile-up tracks are getting confused for primary tracks. And can a couple cm of <sDCA> shift really translate into a factor of x3 drop in # BEMC matches at the same time?

_____________

-Gene