Inconsistently counted beam photon in reconstructed MC/thrown MC at beam energies where TAGH and TAGM overlaps #850
Description
What happened?
This is another subtle issue that differs a bit from the already resolved issue #810 (which create a dip in the reconstructed efficiency). Instead, it results in spike-like structure in the reconstructed efficiency at around beam energy of 8.9 GeV where the tagger hodoscope TAGH#127 overlaps almost entirely with microscope column TAGM#1. Specific beam energies may differ according to different electron beam energy from run to run and different tagger energy scale from run period to run period, but similar spike structure is seen in both ppbar and lamlambar channel reconstruction efficiencies from all run periods in GlueX Phase-I:
How to reproduce the issue and what is the cause?
Further investigation is done using ppbar MC for a single run 30496 from sp17, and no random triggers. The simulation is done using version set 5.21.0. And the beam energy is set to be between 8.880-8.890 GeV. The REST files shows that for each event, the generated beamPhoton is registered as signal in both TAGM#1 and TAGH#127, while the thrown information remains to be only hits at TAGM#1:
Event: 1
DBeamPhoton:
E(GeV): System: Counter: t(ns):
----------------------------------
8.884361 TAGM 1 -4.0
8.888765 TAGH 127 -3.6
DBeamPhoton:TAGGEDMCGEN
E(GeV): System: Counter: t(ns):
----------------------------------
8.884361 TAGM 1 -4.0
and the reconstructed efficiency at this range is estimated to be twice higher than the neighboring bin:
(blue is MC with beam energy range 8.88-8.89 GeV, and red is another MC with beam energy range 8.88-8.90 GeV including the neighboring bin whose efficiency is normal).
The cause seems to be that for each DBeamPhoton:TAGGEDMCGEN that goes into the mcthrown tree, there are twice number of reconstructed photons that end up in the numerator of the efficiency calculation. As shown in the table above, it seems that only TAGM hit is recorded for DBeamPhoton:TAGGEDMCGEN, which is inconsistent from the double counting in DBeamPhoton factory. Hence the efficiency doubled at that energy range. For the entire run period, because of the slightly fluctuating electron beam energy, it is smeared into a spike-like structure as spotted in the plots above.
The sample rest file with 100 events, along with other HDDM files produced during the simulation pipeline, is stored at /w/halld-scshelf2101/home/haoli/test/spike_test/8.880-8.890/hddm.
Which part of the HallD code is relevant?
The double-counted beam photon seems to originated from the Pseudo tagger in HDGeant4 where it allows beam photon to be detected by both hodoscope and microscope respectively. However it might create broader impact if we don't allow beam photon to be detected by both TAGH and TAGM.
Another option might be allow double-counting beam photon in the thrown tree so that the effect cancels out in both numerator and denominator of the reconstructed efficiency calculation.
Where else is affected?
Beside the largely overlapped TAGH#127 and TAGM#1, there is also a small overlapping between TAGH#179 and TAGM#102. Double-counted reconstructed beam photon can also be seen:
Event: 49
DBeamPhoton:
E(GeV): System: Counter: t(ns):
----------------------------------
7.898822 TAGM 102 -0.2
7.856271 TAGH 179 -0.3
DBeamPhoton:TAGGEDMCGEN
E(GeV): System: Counter: t(ns):
----------------------------------
7.898822 TAGM 102 -0.2
what is weirder is that here the two tagger are quite apart from each other. The simulation here is generated with beam energy range 7.860-7.870 GeV. (HDDM file sample at /w/halld-scshelf2101/home/haoli/test/spike_test/7.860-7.870/hddm)