feat: apply dRICH and pfRICH quantum efficiency at photon generation (stacking) stage

[Copilot]

dRICH QE was only applied in downstream digitization, forcing simulation of many photons that are later discarded. This PR moves dRICH QE suppression into npsim generation-time optical stacking, consistent with the existing hpDIRC pattern.

• Generation-stage dRICH QE in npsim.py

  • Added dRICH QE table (wavelength/efficiency) to simulation steering.
  • Configured OpticalPhotonEfficiencyStackingAction for dRICH photosensitive logical volumes (DRICH_pss_sec0..5), so optical photons are filtered before full tracking/digitization.
  • Kept existing hpDIRC stacking configuration in place.

• Stacking action support for non-uniform QE tables

  • Extended OpticalPhotonEfficiencyStackingAction with optional Wavelengths property.
  • Added interpolation on explicit wavelength grids (Wavelengths + Efficiency) while preserving legacy uniform-grid behavior (LambdaMin/LambdaMax + Efficiency).

• Behavioral intent

  • dRICH QE is now applied at generation stage in npsim using the same QE values previously used in reconstruction digitization, reducing wasted optical-photon transport.

# npsim.py (new dRICH stack entries)
{
  "name": "OpticalPhotonEfficiencyStackingAction",
  "parameter": {
    "LambdaMin": "315*nm",
    "LambdaMax": "1000*nm",
    "Wavelengths": [315, 325, 340, ..., 1000],
    "LogicalVolume": "DRICH_pss_sec0",  # repeated for sec0..sec5
    "Efficiency": [0.00, 0.04, 0.10, ..., 0.00],
  }
}

[Copilot]

Pull request overview

This PR moves dRICH and pfRICH quantum-efficiency (QE) photon suppression from downstream digitization into the npsim generation/stacking stage, so unproductive optical photons are killed early. It also generalizes OpticalPhotonEfficiencyStackingAction to accept a non-uniform lambda grid (LambdaValues) and to match logical volumes by regex (needed because dRICH/pfRICH photocathode logical volumes are numbered, e.g. DRICH_pss_sec0..N and PFRICH-photocathode-00..NN).

Changes:

• Generalize OpticalPhotonEfficiencyStackingAction to support LambdaValues (non-uniform grid), regex LogicalVolume matching, and a unified interpolation path via std::call_once initialization.
• Add dRICH and pfRICH QE stacking-action entries to npsim.py, retaining the existing hpDIRC entry.
• Use std::regex_match against compiled regex for per-photon volume filtering.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/plugins/include/npdet/OpticalPhotonEfficiencyStackingAction.h	Adds LambdaValues property, regex volume matching, unified interpolation, lazy initialization.
src/dd4pod/python/npsim.py	Registers generation-stage QE stacking actions for dRICH and pfRICH photocathodes.

Comments suppressed due to low confidence (1)

src/plugins/include/npdet/OpticalPhotonEfficiencyStackingAction.h:136

• Behavior regression for the single-element Efficiency case when only LambdaValues (and not LambdaMin/LambdaMax) is provided. In initialize(), m_interp_lambda_values is only populated when m_efficiency.size() > 1 or m_lambda_values.size() > 1. With Efficiency=[x] and a single LambdaValues=[y], m_interp_lambda_values stays empty, so the range check at lines 78-80 falls back to m_lambda_min/m_lambda_max (defaults of 0), and no photon ever passes the range test. The previous code supported "single constant value over [LambdaMin, LambdaMax] range"; the new code only supports that case when LambdaMin/LambdaMax are also provided. Consider populating m_interp_lambda_values (or otherwise tracking the effective lambda range) for the single-efficiency case as well, or document the constraint.

        if (m_efficiency.size() > 1) {
          if (m_lambda_values.size() == m_efficiency.size()) {
            m_interp_lambda_values = m_lambda_values;
          } else {
            auto lambda_min_nm = m_lambda_min / CLHEP::nm;
            auto lambda_max_nm = m_lambda_max / CLHEP::nm;
            m_interp_lambda_values.reserve(m_efficiency.size());
            auto lambda_step = (lambda_max_nm - lambda_min_nm) / (m_efficiency.size() - 1);
            for (std::size_t i = 0; i < m_efficiency.size(); ++i) {
              m_interp_lambda_values.push_back(lambda_min_nm + i * lambda_step);
            }
          }
        } else if (m_lambda_values.size() > 1) {
          m_interp_lambda_values = m_lambda_values;
        }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Capybara summary for PR 48

• sim_dis_10x100_minQ2=1000_epic_craterlake
• sim_dis_10x100_minQ2=1_epic_craterlake
• sim_dis_18x275_minQ2=1000_epic_craterlake
• sim_dis_18x275_minQ2=1_epic_craterlake
• sim_dis_5x41_minQ2=1_epic_craterlake
• sim_e_1GeV_20GeV_epic_craterlake
• sim_pi_1GeV_20GeV_epic_craterlake
  ^{_{Last updated 2026-05-17T18:48-04:00 6379d10}}

[wdconinc]

OpticalPhotonEfficiencyStackingAction WARN  Suppressed 347927 of 396322 photons (87.8%) in lv DRICH_(gas|aerogel)
OpticalPhotonEfficiencyStackingAction WARN  Suppressed 62128 of 68891 photons (90.2%) in lv PFRICH(_GasVol|-aerogel-[0-9]+-[0-9]+)
OpticalPhotonEfficiencyStackingAction WARN  Suppressed 420093 of 539330 photons (77.9%) in lv bar_vol

[wdconinc]

FYI @chchatte92 This reduces the number of optical photons we need to handle in simulation, speeding up the simulations. Of course, we then cannot again apply QE in the digitization in EICrecon.

https://eic.github.io/npsim/pr/48/capybara/sim_dis_18x275_minQ2=1000_epic_craterlake/index.html#DRICHHits

[chchatte92]

FYI @chchatte92 This reduces the number of optical photons we need to handle in simulation, speeding up the simulations. Of course, we then cannot again apply QE in the digitization in EICrecon.

https://eic.github.io/npsim/pr/48/capybara/sim_dis_18x275_minQ2=1000_epic_craterlake/index.html#DRICHHits

Hi Wouter, so whenever we change the QE in future for our testing purpose, we change directly in here?

Chandra

[wdconinc]

FYI @chchatte92 This reduces the number of optical photons we need to handle in simulation, speeding up the simulations. Of course, we then cannot again apply QE in the digitization in EICrecon.
https://eic.github.io/npsim/pr/48/capybara/sim_dis_18x275_minQ2=1000_epic_craterlake/index.html#DRICHHits

Hi Wouter, so whenever we change the QE in future for our testing purpose, we change directly in here?

You can do either. It's the product that matters. If you want to study the impact of the quantum efficiency, then you'll probably want to run 1 simulation, and then apply QE in EICrecon for multiple assumptions of QE. But for production campaigns it makes more sense to apply the QE here in npsim, so that should be the one that should be correct.