Comparison of SL10j and SL09g production of Run 9 st_W stream

Recently the new production of the st_W stream (SL10j produciton) finished.  I made quick comparison of the usual "W movies" in this new produciton and the production used for W AL paper (SL09g).  Here are 2 movies for comparison of SL09g (PRL analysis histos) and SL10j (using PRL tagged W code).  The main difference I noticed was the number of "goldent Ws" (ie. candidates passing all cuts and have cluster ET > 28 GeV) decreased by ~23% in SL10j (page 13), while the number of L2W triggered events in each produciton is the same to better than 1% (see 5th bin of histon on top of page 1).

To try and understand these "missing events" better I looked at the events that passed all the W cuts in SL09g, but didn't reconstruct as Ws in the new SL10j production (list of events).  Since some of the SL09g production is no longer on disk there are only 289 events that pass all the W cuts on disk for SL09g.   Of these 289 event, 65 of them don't pass the W cuts in SL10j (~22%), which is consistent with the full dataset comparison in above.  Figure 1 shows the cluster ET distribution for these 65 events, and its pretty clear that there are some real signal W events in this sample.

Figure 1:  2x2 Cluster ET distribution for events found in SL09g, and not found in SL10j

Also the candidate track PT plot for these events is typically well above the 10 GeV cutoff

Figure 2: Event loss histogram from SL10j for W events found in SL09g, and not found in SL10j

The event loss histogram for these 65 events in SL10j shows clearly that the majority of events are lost because there is no track reconstructed with PT > 10 GeV.  Both the time dependence and position (eta, phi) of these tracks missing in SL10j were checked and no obvious pattern was found.

Another question that was brought up was whether these tracks are not reconstructed or if they are just reconstructed with a smaller PT, and thus failed the PT cut.  Figure 3 shows the track pt distribution for these 65 events before any tracking cuts are applied.  For SL09g, there is ~1, pt > 10 track per event as expected for good W candidates.  For SL10j there are 23 tracks with pt > 10, of which only 7 survive our track QA cuts of nHit > 15, nHit/nHitPoss > 0.51, rMin < 90 and rMax > 160.

Figure 3: Primary track PT distribution before any track cuts are applied: SL09g (left) and SL10j (right)

So obviously some of these high PT tracks are removed by our standard track QA cuts.  Figure 4 and 5 show those track QA parameters for tracks with pt > 10 for these 65 events in SL09g and SL10j, respectively. 

Figure 4: Track QA distributions for SL09g

Figure 5: Track QA distributions for SL10j

The distributions for SL10j look considerably worse than SL09g even with the small statistics set. 

Simulation tests

As a test of the software changes between SL10j and SL09g I ran a small simulation 1200 W+ events in both SL09g and SL10j with the following chain options below.  The goal was to see if some (unknown) change in the track reco software could cause the effects described above.

"tpcrs,y2009a,MakeEvent,ITTF,NoSsdIt,NoSvtIt,Idst,BAna,l0,Tree,logger,Sti,VFPPVnoCTB,tpcDB,TpcHitMover,TpxClu,

bbcSim,tofsim,tags,emcY2,EEfs,evout,IdTruth,geantout,big,fzin,McEvOut,MiniMcMk,eemcDb,beamLine,clearmem"

I used two DbV timestamps for each library to match DbV used in the data production:

1) DbV20101214

Linked are the event loss histograms for SL09g and SL10j.  The result is that ~5% less tracks with PT > 10 are reconstructed in SL10j than SL09g, which is significantly smaller than the loss of ~23% seen between the data producitons.  It's worth mentioning that there may have been several changes to TpcRS between the 2 libraries which could effect the difference in reconstruction efficiencies seen in the simulation.

2) DbV20091225

Linked are the event loss histograms for SL09g and SL10j.  Again the result is that ~5% less tracks with PT > 10 are reconstructed in SL10j than SL09g.  The SL09g sample matches exactly with the other timestamp used above, and the SL10j sample matches ~exactly aside from a small difference in the BTOW calib table used in the simulation.

tpcAnodeHV vs. tpcAnodeHVavg

It turns out that between SL09g and SL10j libraries there was a change in the DB table used to load tpcAnodeHV values.  In the SL09g production tpcAnodeHV tables were used, but in the SL10j production tpcAnodeHVavg tables were used.  See note in library history

...

StiTpc
StiTpcDetectorBuilder.cxx, StiTpcDetectorBuilder.h - replaced St_tpcAnodeHVC by St_tpcAnodeHVavgC;

...

Gene is looking into what differences there might be between the 2 tables used in the different productions, and how it might effect the comparison being made here.