Off-timing combos are seen when using "dComboBeamWrapper->Get_IsGenerator()" selection

[keigo-miz]

In the above figure, DeltaT_RF distributions for MC analysis are shown.

The black histogram is for all combos without any cuts in DSelector.
The red one is for combos which satisfy "dComboBeamWrapper->Get_IsGenerator() == true".

To my understanding, only on-timing peak should be seen when the true beam photons are selected using Get_IsGenerator method, but small off-timing peaks are seen only in left-hand side. Does this imply bugs are lurking around Get_IsGenerator function?

[jonzarling]

Hi Keigo,

I did a deep dive into this maybe a year ago, hopefully I can save you some time here. This isn't really directly a gluex_root_analysis issue: the step where combos are incorrectly labeled "IsGenerator" happens far upstream. If I remember right, it actually originates as far back as hdgeant4, not even halld_recon. Perhaps a catch could be implemented in gluex_root_analysis to prevent any future confusion.

The Get_IsGenerator function is more of a "best guess" than anything. The algorithm for 'IsGenerator" first picks out beam photons that hit the correct tagger channel. Usually there is only one, but if there are multiple it picks out the one closest to 0 in the Delta t shown in the plot above. It doesn't use any timing cut, so it will pick out wrong beam photons like you show. I never figured out why they only show up on one side of the distribution, but I saw the same behavior.

This also means that there are accidentals under the peak around 0, where the true photon is inefficient but another lucky photon happens to be in-time and hit the correct tagger channel. So using IsGenerator in an analysis will overestimate the true efficiency.

[jonzarling]

The potentially scary bit is that the same logic applies to the mcthrown_tree plugin that I think most people rely on for efficiency determination. I suggest we close the issue here and reopen an issue in halld_recon mentioning the mcthrown_tree.

For what it's worth, here's what it looks like for me. In my analysis it was a 0.5% overcount with Spring 2017 conditions. It might be higher for later run periods running at higher rate.

[keigo-miz]

Hi Jon, thank you very much for your explanation.
I agree with your suggestion, but can you open an issue in halld_recon for me? (I've never used mcthrown_tree plugin.)
I'm gonna close this issue after the issue is reopened in halld_recon.

[sdobbs]

I wonder if there's some cross over with this issue - JeffersonLab/halld_recon#810

[lihaoahil]

Are those the simulations with or without random triggers? I took a quick look at my some of my recent simulation result but I don't see this happen.