-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with TAGGEDMCGEN Factory: Tagger Hits from Random Triggers Matched with the Real "MCGEN" Beam Photon #810
Comments
Thanks for pointing this out - this is probably due to the channel quality table being updated after the random trigger files were created. I made a halld_recon branch named This is probably okay for now, but as the dead channel tables are being used more often, we should use the same logic (at the HDDM event reader stage) for other detectors. |
@lihaoahil - just giving this a bump, could you please check the branch I mentioned above to see if this solves your problem? |
@sdobbs - no problem, I am going to give it a try now. |
@lihaoahil - did you have a chance to test this? |
With the new version sets compatible with Alma9 on the farm, I finally get to test the branch |
It appears that there might be a subtle issue/bug in the
DBeamPhoton:TAGGEDMCGEN
factory. Specifically, tagger hits originating from random triggers are being incorrectly matched with the realDBeamPhoton:MCGEN
beam photon. This matching issue could potentially lead to inaccuracies and dip structure in the estimated tagged efficiency when random triggers are present in the mcsmear.The issue was found during investigation of the unexpected dip structure in baryon-antibaryon's beamE dependent efficiencies at around 7.8 GeV (page 6 slides). Further check of one run #30496 of spring 2017 simulation shows that at one hodoscope tagger #186 at around 7.75 GeV, the mcthrown tree has counts but none in the reconstructed tree:
, and it results in a hole of the efficiency.
summing over all runs, because of the slightly fluctuating
PHOTON_BEAM/endpoint_energy
, this hole gets smeared to a dip-like structure.As checked by @jrstevenjlab, TAGH counter186 is masked with code=2 in the CCDB. Since the channel is masked, it is expected to not see any counts in the corresponding energies in both
mcthrown
tree and reconstructedantip__B4_Tree
. The fact that there are still counts in themcthrown
tree means that it mistakenly think that the generator beam photon produced a tagger hit, but it is actually just a background hit that happens to be in the same counter.To reproduce this issue, I made 100 ppbar signal events with and without random triggers in the beamE range 7.740-7.745 GeV, which should be fully contained in TAGH counter 186. The run number assigned is 30496 and the env file is
/group/halld/www/halldweb/html/halld_versions/recon-2017_01-ver03_39.xml
. The hddm files are located at:/w/halld-scshelf2101/home/haoli/test/tagh186_test_signal_7740_7745/hddm/dana_rest_mc_gen_030496_000.hddm
/w/halld-scshelf2101/home/haoli/test/tagh186_test_withBKG_7740_7745/hddm/dana_rest_mc_gen_030496_000.hddm
By command
hd_dump -DDBeamPhoton:MCGEN -DDBeamPhoton:TAGGEDMCGEN -DDBeamPhoton:TRUTH
, we can see that when random triggers are included:where the
DBeamPhoton:TAGGEDMCGEN
factory matched one background photon with wrong timing.When the random triggers are turned off, the wrongly matched
DBeamPhoton:TAGGEDMCGEN
all disappeared.Further impact: I am not sure if other weird structures in my efficiency have anything to do with it, as other TAGH/TAGM counters are not masked and the
DBeamPhoton:TAGGEDMCGEN
will most likely be matched with a photon from mc truth. But it may still be possible to have a few percent of the cases, whenever an event is excluded due to tagger hit selection, but the mcthrown events somehow survived due to mistakenly matched background photons, causing the local efficiency to be biased.The text was updated successfully, but these errors were encountered: