- drach09's home page
- Posts
- 2022
- 2020
- June (1)
- 2019
- 2018
- 2017
- 2016
- 2015
- 2014
- December (13)
- November (2)
- October (5)
- September (2)
- August (8)
- July (9)
- June (7)
- May (5)
- April (4)
- March (4)
- February (1)
- January (2)
- 2013
- December (2)
- November (8)
- October (5)
- September (12)
- August (5)
- July (2)
- June (3)
- May (4)
- April (8)
- March (10)
- February (9)
- January (11)
- 2012
- 2011
- October (1)
- My blog
- Post new blog entry
- All blogs
2006 EEMC Neutral Pions: Single-beam Backgrounds (part 7)
Doing a first-order scan (~70 runs) of things, it looks like the vertex cut is the biggest hammer, cutting ~40% of the total eemc-http events. This takes the sample from somewhere around 60% coincidence to 80% coincidence (tightening up the zvertex cut seems to have no effect on the relative percentages). Still, only ~35% of events contain a reconstructed di-photon. Of those, the sample is still around 80% coincidence (78.8% to be more accurate). It's possible these numbers will fluctuate as I integrate more runs, but this sample seems fairly consistent with previous studies.
The reconstruction is, at this point, completely opaque. I would have to rerun the trees to see where events are rejected. However, given that the relative percentages change not at all going from having a di-photon to having no-diphoton, I'm inclined to think the issue lies elsewhere.
Once I have di-photons the biggest cut appears to be the mass restriction. Scanning different cut windows (e.g. 0-2, 0-1, 0.1-0.2, 0-0.1 GeV/c2) seems to have no visible effect on the relative percentages which all seem to hover around 77-78% coincidence.
When I enforce the software trigger requirement, I begin with ~95% coincidence events and none of the cuts seem to change that percentages, all the way through to the mass reconstruction. So, while the vertex cut changes the percentage (60% to 80%) when not enforcing the software trigger; it has no effect when the software trigger is enforced.
One possible issue I found is I do not see a vertex rank cut in these data. Steve and I discussed this way back in the summer, but the cut was never applied. Recall, for awhile we were planning to use the BBC-timebins before we decided to skip them in order to keep the backgrounds more consistent, so I guess the vertex rank for TPC vertices got overlooked. My intuition is cutting on vertex rank will move things in the right direction, but I don't know if it would do it by ~10%. I also wouldn't expect this to resolve the discrepancy between software trigger and no-software trigger events.
Groups:
- drach09's blog
- Login or register to post comments