gain_factor: PbGlass gain correction is never loaded, GainCorrTable::g[] is always 1.0 (576 PbGlass modules uncorrected)

[Chao1009]

Where

• GainCorrTable has a PbGlass table g[MAX_G]: https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/include/gain_factor.h#L168-L184
• LoadGainCorrTimeSeries fills only corr.w[]: https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/include/gain_factor.h#L376-L391
• LoadRefGainFile parses G lines into RefGainTable::g[], which nothing reads: https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/include/gain_factor.h#L135-L141
• Consumers read gain_corr.g[id].avg for PbGlass:
  • https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/src/Replay.cpp#L569-L578 (Process, the gain_factor branch)
  • https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/src/Replay.cpp#L1047-L1050 (ProcessWithRecon)
  • https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/src/Replay.cpp#L1617-L1620 (ProcessRaw2Recon)
• The upstream producers skip PbGlass:
  • https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/src/GainCorrCompute.cpp#L309-L318
  • https://github.com/JeffersonLab/prad2evviewer/blob/d21ae9f/analysis/tools/refGain_produce.cpp#L269

What happens
GainCorrTable::Entry defaults to avg = 1.f. LoadGainCorrTimeSeries writes only b.corr.w[wi + 1], and no code anywhere writes GainCorrTable::g[]. As a result, gain_corr.g[id].avg is 1.0 for every PbGlass module in every batch of every run.

The effect:

• The raw replay writes gain_factor = 1.0 for all 576 PbGlass channels (the count comes from database/hycal_map.json).
• Reconstruction (ProcessWithRecon, ProcessRaw2Recon) feeds PbGlass hits to the clusterer with no LMS gain-drift correction.
• In ProcessRaw2Recon, the gain == 1.0f fallback to in->gain_factor[j] finds 1.0 there as well.

The comment in Replay.cpp ("Gain correction is HyCal-only (PbGlass / PbWO4)") and the PbGlass branches suggest the correction is applied, but it never is, and nothing warns about it.

The data needed for the correction does not exist either:

• The header comment (gain_factor.h L17) already says G corrections are not stored.
• GainCorrCompute fills histograms only for MOD_PbWO4 and MOD_LMS.
• refGain_produce skips every type other than PbWO4/LMS.
• None of the 12 files in database/gain_factor/ref_gain/*.dat has a G line.
• gain_corr.root has only gain_W, gain_W_ref, gain_corr_W and fit_mean_W_lms.

So RefGainTable::g[] and the G parsing branch are dead code.

Evidence

// gain_factor.h L376-391: only the PbWO4 table is filled
for (int wi = 0; wi < kNW; ++wi) {
    ...
    b.corr.w[wi + 1].corr[j] = v;
    ...
    b.corr.w[wi + 1].avg = sum / static_cast<float>(kNLMS);
}

// Replay.cpp L574-575: always 1.0
} else if (mod_type == prad2::MOD_PbGlass) {
    ev->gain_factor[nch] = gain_corr.g[mod_id].avg;

To reproduce, run any raw replay with a gain_corr.root present. The gain_factor branch is exactly 1.0 for every channel with module_type == PbGlass.

Suggested fix
Pick one of two directions:

1. Add PbGlass correction. Keep the PbGlass LMS peaks in refGain_produce and GainCorrCompute (write G lines, plus gain_G / gain_G_ref / gain_corr_G[900][3] branches). Then fill b.corr.g[gi + 1] in LoadGainCorrTimeSeries in the same way as w, and read RefGainTable::g[] where the reference ratio is built.
2. If PbGlass correction is out of scope on purpose, make that explicit:
   • Remove RefGainTable::g[], GainCorrTable::g[] and the G parse branch.
   • Return 1.f for PbGlass ids with a comment saying so.
   • Fix the "PbGlass / PbWO4" comment in Replay.cpp.
   • Optionally, log once at load time that PbGlass channels are not gain-corrected.

Status
Still present on dedup-refactor. The call sites now go through GainCorrTable::ModuleGain(), which returns g[id].avg for PbGlass ids, and LoadGainCorrTimeSeries still fills only corr.w[].