- 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
Pileup in pp500 BeamLine constraint
When attempting a Run 9: pp500 Low Luminosity Fill, I got a glimpse of how big an issue pileup was going to be. When I first processed some mildly high luminosity pp500 data from day 83 (fill 10415, daq files from runs 10083013-56 were on disk), I found it a bit difficult to apply cuts to get rid of pileup. One place where pileup is easy to see is in the x position of vertices at large z. Here we can see that particularly at high vertex ranking (right plot) there are two peaks in the x position (shown versus multiplicity of the vertices for low and high ranked vertices separately):
A hint that the peak with higher x values is from the non-pileup distribution comes from its extension into high multiplicities, but it isn't solid evidence. Even more evidence comes from not weighting the vertices by their errors, which demonstrates that the low x value vertices have larger errors associated with them:
Note that I have used the VFMinuit3 chain option which supposedly gives lower ranking to split vertices. I do not know if this is appropriate (should I be using VFMinuit2?).
So I modified Minuit to instead use something akin to what PPV does, allowing rejection of tracks which appear to be PCTs (post-crossing tracks):
bool StMinuitVertexFinder::isPostCrossingTrack(StTrack* track) const{ const float zMax=200; const float zMembraneDepth=1.0; const int nWrongZHitCut=2; int nWrongZHit=0; StPtrVecHit hits = track->detectorInfo()->hits(kTpcId); for (unsigned int i=0;i<hits.size();i++) { StTpcHit* sthit = (StTpcHit*) hits[i]; if(sthit){ StTpcHit* hit=(StTpcHit*) sthit; float z=hit->position().z(); if (fabs(z) > zMax) continue; if (z < -zMembraneDepth && hit->sector() <= 12 || z > zMembraneDepth && hit->sector() > 12) { nWrongZHit++; if(nWrongZHit>=nWrongZHitCut) {return true;} } } } return false; }
Re-running the same data sample now results in plots as shown here:
The peak with high ranking at smaller x values has considerably shrunk, proving that it was comprised predominantly of pileup vertices.
I plan to use this modified Minuit vertex finder for the remainder of the BeamLine calibrations unless something better comes along.
-Gene
- genevb's blog
- Login or register to post comments