- genevb's home page
- Posts
- 2024
- 2023
- 2022
- September (1)
- 2021
- 2020
- 2019
- December (1)
- October (4)
- September (2)
- August (6)
- July (1)
- June (2)
- May (4)
- April (2)
- March (3)
- February (3)
- 2018
- 2017
- December (1)
- October (3)
- September (1)
- August (1)
- July (2)
- June (2)
- April (2)
- March (2)
- February (1)
- 2016
- November (2)
- September (1)
- August (2)
- July (1)
- June (2)
- May (2)
- April (1)
- March (5)
- February (2)
- January (1)
- 2015
- December (1)
- October (1)
- September (2)
- June (1)
- May (2)
- April (2)
- March (3)
- February (1)
- January (3)
- 2014
- December (2)
- October (2)
- September (2)
- August (3)
- July (2)
- June (2)
- May (2)
- April (9)
- March (2)
- February (2)
- January (1)
- 2013
- December (5)
- October (3)
- September (3)
- August (1)
- July (1)
- May (4)
- April (4)
- March (7)
- February (1)
- January (2)
- 2012
- December (2)
- November (6)
- October (2)
- September (3)
- August (7)
- July (2)
- June (1)
- May (3)
- April (1)
- March (2)
- February (1)
- 2011
- November (1)
- October (1)
- September (4)
- August (2)
- July (4)
- June (3)
- May (4)
- April (9)
- March (5)
- February (6)
- January (3)
- 2010
- December (3)
- November (6)
- October (3)
- September (1)
- August (5)
- July (1)
- June (4)
- May (1)
- April (2)
- March (2)
- February (4)
- January (2)
- 2009
- November (1)
- October (2)
- September (6)
- August (4)
- July (4)
- June (3)
- May (5)
- April (5)
- March (3)
- February (1)
- 2008
- 2005
- October (1)
- My blog
- Post new blog entry
- All blogs
Effects of StiNodePars.h change
Joe Seele found some evidence that high pT tracks were being lost due to a single line of code changed between SL10f and SL10g in Sti/StiNodePars.h. So I tried processing ~1000 events from a Run 9 st_W file (st_W_10103041_raw_4180001), yielding almost 1M global tracks with flag>0, in both the standard SL10g, and SL10g_mod (where I changed the single line of code back to that from SL10f, and also re-compiled the dependent libraries of Sti, StiMaker, and StDetectorDbMaker). I then used code I had to match tracks between the two productions, requiring the following for a match:
- Same event
- Same charge sign
- |Δη| < 0.1
- |Δ(Zproj)| < 12 cm
- |Δ(Ψ)| < 10 °
where Zproj = Zfirst - Rfirst * (Zlast-Zfirst)/(Rlast-Rfirst) [roughly a projection to the z-axis]. Nearly all tracks got matched (910 are unmatched from SL10g_mod, and 892 from SL10g, with 973214 matched tracks), but it's interesting to learn from the small differences.
First, the effects on matched tracks are essentially negligible. For example, the h-/h+ issue is on the scale of d(1/pT)/q ~ 0.002, but the differences here are on the level of 10-(5±1) or so.
Turning to the unmatched tracks, these are the log10(pT) and Nhit distributions unmatched in SL10g (back set) and SL10g_mod (front set):
There's definitely an alteration of high pT tracks due to the code change. There seem to be some effects in the Nhit distribution too.
Here are the distributions of unmatched/matched tracks for these same two observables, with red for SL10g_mod, and blue for SL10g:
The ratio for SL10g_mod exceeds 1 at very high pT (so more tracks are unmatched than matched)! The Nhit distributions are similar. The same data is shown here in log scale:
Plotting vs. both quantities (for SL10g_mod on the left and SL10g on the right, set to the same vertical scale):
So the unmatched tracks are worst from SL10g at high pT and perhaps even increasing in percentage with increasing Nhit, until the statistics expire at high pT and high Nhit. Here are the stats from the unmatched tracks.
-Gene
[note: this page was updated from an initial version after slightly loosening cuts to ensure unmatched tracks were really un-matchable, and after a bug fix which prevented some unmatched tracks from being recorded]
- genevb's blog
- Login or register to post comments