Update trigger for use with a trigger plane and ensure backscatter is excluded

As spotted by @anatolii.korol, there are (rare) edge cases close to a geometrical region excluded from fast sim where secondaries created in a full sim shower can cross the trigger boundary and cause unwanted fast sim triggers inside the calorimeter. This MR proposes a fix for this with two important steps:

1. Adding a trigger plane to the compact file right at the front of the calorimeter face (and of course adjusting the model.RegionName in scripts/ddsim_steer.py ).

   E.g. for the ECAL Barrel of ILD_l5_o1_v02.xml this would mean creating a local copy of k4geo and modifying SEcal06_hybrid_Barrel.xml accordingly:

   diff --git a/ILD/compact/ILD_common_v02/SEcal06_hybrid_Barrel.xml b/ILD/compact/ILD_common_v02/SEcal06_hybrid_Barrel.xml
   index 457246d..d66595f 100644
   --- a/ILD/compact/ILD_common_v02/SEcal06_hybrid_Barrel.xml
   +++ b/ILD/compact/ILD_common_v02/SEcal06_hybrid_Barrel.xml
   @@ -5,8 +5,35 @@
        </region>
      </regions>
    
   +  <regions>
   +    <region name="EcalBarrelFastSimTriggerRegion">
   +    </region>
   +  </regions>
   +
   +  <readouts>
   +        <readout name="ECalBarrelFaceReadout">
   +            <id>system:5,side:2,layer:9,module:8,sensor:8</id>
   +        </readout>
   +    </readouts>
   +
      <detectors>
    
   +    <detector name="EcalBarrelFastSimTrigger" type="PolyhedralBarrelSurfaces" region="EcalBarrelFastSimTriggerRegion" readout="ECalBarrelFaceReadout">
   +      <comment> EM Calorimeter Fast Sim Trigger Region </comment>
   +       
   +      <envelope vis="ILD_ECALVis">
   +        <shape type="PolyhedraRegular" numsides="Ecal_symmetry"  rmin="Ecal_inner_radius - 3*env_safety" 
   +        rmax="Ecal_inner_radius - 2*env_safety" dz="2.*Ecal_half_length + env_safety"  material = "Air" />
   +        <rotation x="0*deg" y="0*deg" z="-180*deg/Ecal_symmetry"/>
   +      </envelope>
   +      
   +      <dimensions numsides="Ecal_symmetry" rmin="Ecal_inner_radius - 3*env_safety" 
   +      rmax="Ecal_inner_radius - 2*env_safety" zhalf="Ecal_half_length"
   +      phi0="-180*deg/Ecal_symmetry" material = "Air" />
   +
   +  </detector>
   +
   +
        <detector name="EcalBarrel" type="SEcal06_Barrel" id="ILDDetID_ECAL" readout="EcalBarrelCollection" vis="ILD_BlueVis"
         region="EcalBarrelRegion">
   

2. Ensure that backscatter from the calorimeter does not cause model triggers (see changes to src/OctogonalBarrelTrigger.cc)

Validation checks performed so far (with 2025-01-28 key4hep release):

• particle gun into calo in FastSim region

  position: (0, 0, 0), direction: (0 1 0), particle: gamma, energy: 50 GeV

  Results: Triggers Fast Sim (expected behavior)

• particle gun inside calo (firing backwards) in FastSim region

  position: (0, 1860, 0), direction: 0 -1 0, particle: gamma, energy: 50 GeV

  Results: Does not trigger Fast Sim (expected behavior)

• particle gun into calo region excluded from FastSim (corner of barrel)

  position: (0, 0, 0), direction: (-0.4152 1 0), particle: gamma, energy: 50 GeV

  Results: Does not trigger Fast Sim (expected behavior)

@anatolii.korol would you be able to quickly check if this resolves the issue you were seeing?

requested review from @thomas.madlener

assigned to @peter.mckeown

changed the description

added 1 commit

• 33822456 - format files for pre-commit

Compare with previous version

added 1 commit

• d1d3b1a2 - format files for pre-commit

Compare with previous version

Do I understand correctly that the changes in the detector geometry, effectively create a very thin volume of thickness env_safety?

I am not yet entirely sure what the best solution for this is in the end. Ideally, something could be done without having to touch existing geometries, e.g. via checking that secondaries enter through the right face of the trigger volume. However, I am also not really sure if that is a truly scalable approach either.

Yeah, that is the suggestion. Having to modify the existing geometries is not optimal, and of course requires some care. There are other options, but I think they come with possible overheads in other ways. For example, one option we considered would be adding some kind of FastBit in the DD4hep ParticleHandler that is set once a particle is excluded from fast sim, and would then be inherited by all daugthers, but this of course adds quite a bit and would then require constant checking for secondaries that are created. Another option goes along the lines of what you suggest, and would involve checking if the secondary is in the volume of the calorimeter, but so many additional geometry checks could add a lot of overhead.

But of course there could also be better ways of doing this we just haven't thought of yet. I think generally a more robust approach is needed for the trigger, as it currently assumes a straight flight path from the IP, and this is of course not the case for charged particles.