Update Trigger Apparatus to store multiple hit information from TDCs

[mrcmor100]

Although multiple hits from the TDCs are decoded using Podd, only one good hit was selected and saved to the TTree. A new set of branches are available: T.._vecTdcTimeRaw and T.._vecTdcTime

The first hit of these vectors corresponds to the good hit selected in T.._tdcTimeRaw and T.._tdcTime.
All good hits that pass a timing window cut are saved. If no good hits were found in the timing windows, the event closest to the TimeWindowMin is selected. If no hits were found in that TDC, the tdcTime and tdcTimeRaw values are set to zero.

See HCLOG entry 4224528 for a testing script, and comparison output.

[mrcmor100]

Please Squash this commit if/when accepted.

[sanghwapark]

I also checked a couple of runs, and it looks good to me. @MarkKJones

[mrcmor100]

Hello all,    I noticed that the previous way the class worked, the code would only accept the first good hit within the window. Subsequent checks were skipped because it required good_hit==999.  This is why I use thit instead of good_hit to push back the vector of tdc hits if the timing window conditions are met.  This shouldn’t go out of range, but there is no esolicit check.    So it assumes an ordering.  It is ordered the way we expect with the first good but being closest to the timewindowmin.    Using this assumption I could skip the sorting of the vector.  The case where closest hit is just outside the timing window would only appear when the vector is empty.  It wouldn’t speed up much since MOST of the time there is just one hit, so sorting a single number is pretty quick. Cheers,Casey MOn Nov 22, 2023, at 12:03 PM, Sanghwa Park @.***> wrote: I also checked a couple of runs, and it looks good to me. @MarkKJones

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[MarkKJones]

Thanks for checking. I did a squash and merge.