GEM_matching: sum-trigger energy cut is missing fabs, accepts every cluster below Ebeam+3σ

[Chao1009]

Where

• Cut: https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/tools/GEM_matching.cpp#L242-L244
• Symmetric helper in the same file: https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/tools/GEM_matching.cpp#L209-L212

What happens

The single-cluster sum-trigger selection is meant to be an Ebeam ± 3σ window (σ = 3.3%·√E). Because the difference is not wrapped in fabs, it only sets an upper bound. Every cluster with E < Ebeam + 3σ passes, all the way down to the trigger threshold. These events fill the energy-integrated histograms: h1_deltaX_gem, h1_deltaY_gem, h2_deltaXY_gem, h1_deltaX_hycal, h1_deltaY_hycal, h2_deltaXY_hycal and h1_Nhits_matched_{0..3}. The energy_bins/ histograms are filled from the 3-cluster branch and are not affected.

Numbers from a 19.7k-event recon sample of run 24246 (Ebeam = 3488.43 MeV, 3σ = 184.9 MeV):

selection	events	HyCal−GEM residual RMS dx / dy
current (one-sided)	2952 (= h1_deltaX_gem entries)	1.81 / 1.78 mm
symmetric ±3σ	2485	1.77 / 1.72 mm
extra events only	467 (15.8% of current sample)	2.02 / 2.07 mm

The 467 extra clusters have energies from 1152 to 3303 MeV (median 3128 MeV). They are not beam-energy events, and they broaden the integrated residual distributions that are used for the matching and alignment checks.

Evidence

// L209-212
static bool inEnergyWindow(float energy, float center)
{
    return std::fabs(energy - center) < 3.f * 0.033f * std::sqrt(center * 1000.f);
}

// L243-244
if (ev.n_clusters == 1 && ev.matchNum == 1 && ev.cl_nblocks[0] > 1 &&
    (ev.cl_energy[0] - gRunConfig.Ebeam) < 3.f * 0.033f * std::sqrt(gRunConfig.Ebeam * 1000.f)) {

Other tools apply the same single-cluster Ebeam ± 3σ cut two-sided:

• https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/tools/hycal_shower_profile.cpp#L414
• https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/tools/time_recon_check.cpp#L386

To reproduce:

1. Run prad2ana_GEM_matching prad_024246.00000_recon.root -o out.root.
2. Compare the entry count of h1_deltaX_gem with the number of recon events that have the sum trigger bit, n_clusters == 1, match_num == 1, cl_nblocks[0] > 1 and |cl_energy[0] - Ebeam| < 3σ.

The histogram has more entries, and every extra event has energy below Ebeam - 3σ.

Suggested fix

Use the helper that is already in the file:

if (ev.n_clusters == 1 && ev.matchNum == 1 && ev.cl_nblocks[0] > 1 &&
    inEnergyWindow(ev.cl_energy[0], gRunConfig.Ebeam)) {

This reduces the entries in the integrated histograms (2952 → 2485 in the sample above), so outputs made before the fix are not directly comparable with outputs made after it. If the low-energy tail was meant to be kept, replace the implicit "no lower bound" with an explicit lower bound and a comment.

Status

Still present on the dedup-refactor branch (analysis/tools/GEM_matching.cpp L199-200). It was left unchanged there on purpose so the refactor's outputs stay identical, so it needs a separate fix.