This is a comparison of TPC residuals in SL09g vs. the current DEV (as of May 20, somewhere between SL10g and SL10h) using StiPulls, triggered by some Understanding Track <z> Distribution Justin Stevens has done with the Run 9 pp500 data showing a prominent group of tracks which start near the central membrane. I processed one file (with 250 events) in the two libraries:

root4star -b -q -l 'bfc.C(10000,
  "pp2009c ITTF VFPPVnoCTB BEmcChkStat beamLine Corr4 OSpaceZ2 OGridLeak3D -dstout -evout StiPulls",
  "/star/data03/daq/2009/Weve/sampler100/st_W_10090047_raw_7170001.daq")'

I then plotted three quantities versus hit Z for reasonable quality tracks (including some anti-pile-up cuts) crossing the central membrane.

1. top: Profile of sqrt(res_x²+res_z²)
2. middle: Spread profile of res_x
3. bottom: Spread profile of res_z

where res_x is the residual along the padrows and res_z is the residual in the drift (z) direction, and "Spread profile" means error bars represent RMS, not error on the mean, as with "Profile". SL09g is first (left), and DEV is second (right), scales are in [cm]:

The error bars in the profile plot reveal the fact that many more tracks passed my cuts for SL09g than DEV (2400 vs. 686), leading to a fair bit of scatter in the dev plot. This appears to be mainly a difference in the impact of the "mHitsG.mVertex==1" cut I use to select hits on global tracks which have a primary partner with the highest ranked primary vertex. I am not sure of the reason for this impact. Vertex ordering issues were resolved before SL09g.

But the biggest issue revealed is the over 1 mm difference in res_z across the central membrane in SL09g which, for some reason, is not apparent in DEV. This is true for all sectors, but particularly at smaller radii. This is demonstrated by these plots of res_z vs. phi and z and vs. padrow and z (here I used only two z bins between -10 and +10 cm to emphasize the region of difference), and then vs. padrow and z again with more z bins.

Sector 20 is the red bin in the phi plot and is often a questionable sector. It and the opposing sector 4 are excluded from the padrow plot, but all sectors show an east-west difference anyhow. It is curious that the bigger res_z shifts appear further out in radius for the west (z > 0) half than the east (z < 0).

No DbV timestamp was used in my production, so the DB values should be the same. I found that not to be strictly true in that there somehow appear to be default tpcSectorPosition entries for 20081215, one of which ends up being used for sector 11 only (since the calibration of sector 11 was unsuccessful for Run 9 data and a new DB value is not used). However, I have not found any 20081215 entries in either the DB or in the CINT files under $STAR. ??? Regardless, that issue is not affecting all sectors as is the difference in res_z.

Drift velocity would be an obvious first guess, but these appear to be the same. Nor do I see any difference in any TPC T0s and clock frequency loaded and listed. StMagUtilities seems to use the same input parameters.

That leaves only code differences. Certainly there was a change for how StMagUtilities handles post-membrane hits, and some other changes for the StTpcHitMover code to be used in simulations. Whatever the changes were, perhaps we're simply getting a better match now with the mVertex cut to the triggered primary vertex and this is giving us less pile-up tracks?

For now it's not clear to me why this difference has gone away....

Meanwhile, there is good news in seeing no significant artifacts in the residuals along the padrows, res_x!

-Gene