Skip to content
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

Open
lihaoahil opened this issue Apr 29, 2024 · 5 comments

Comments

@lihaoahil
Copy link
Contributor

lihaoahil commented Apr 29, 2024

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 real DBeamPhoton: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:
Screenshot 2024-04-29 at 18 49 36, 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 reconstructed antip__B4_Tree. The fact that there are still counts in the mcthrown 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:

  • without random triggers: /w/halld-scshelf2101/home/haoli/test/tagh186_test_signal_7740_7745/hddm/dana_rest_mc_gen_030496_000.hddm
  • with random triggers: /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:

DBeamPhoton:MCGEN
   E(GeV): System: Counter: t(ns):
----------------------------------
 7.744133    TAGH      186   -8.0 

DBeamPhoton:TAGGEDMCGEN
   E(GeV): System: Counter: t(ns):
----------------------------------
 7.745474    TAGH      186  -58.4 

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.

@sdobbs
Copy link
Contributor

sdobbs commented May 8, 2024

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 sdobbs_tagger_dead_channels where the issue should be resolved - could you please check this?

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.

@sdobbs
Copy link
Contributor

sdobbs commented Aug 8, 2024

@lihaoahil - just giving this a bump, could you please check the branch I mentioned above to see if this solves your problem?

@lihaoahil
Copy link
Contributor Author

@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.

@sdobbs
Copy link
Contributor

sdobbs commented Aug 22, 2024

@lihaoahil - did you have a chance to test this?

@lihaoahil
Copy link
Contributor Author

With the new version sets compatible with Alma9 on the farm, I finally get to test the branch sdobbs_tagger_dead_channels after rebasing it onto the latest master (version 4.51.0):
Screenshot 2024-10-07 at 19 20 30
where blue is the beam energy dependent efficiency of the ppbar channel over the entire sp17 run period with 1M events reconstructed with halld_recon 4.51.0, and red is the same MC statistics with the fix from the branch sdobbs_tagger_dead_channels.
Thanks for fixing that! @sdobbs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants