[WIP] Add flag for fast simulation to MCParticle

[tmadlener]

BEGINRELEASENOTES

• Add a flag to the MCParticle to track whether it has been handled by a fast simulation model

ENDRELEASENOTES

This is the start of this work. The goal in the end is to have an easy way in analysis to check whether an MCParticle has been handled by a fast simulation model or not. This will obviously also require EDM4hep and LCIO to acquire a similar flag, but I would like to finalize a few things here first before going there.

Currently there are a few open questions:

• Should we have multiple of these flags to disambiguate whether a particle has been fast simulated only in parts of the detector (i.e. probably FAST_SIMULATION_TRK and FAST_SIMULATION_CALO? Or do we simply name this current flag appropriately to _CALO (as that is the main / only use case for this)?
• Should setting this flag be responsibility of implementors of actual fast sim models, or can we still handle it on the DD4hep side? (The only place where we could conceivably do that would be in the Geant4FastSimShowerModel::check_trigger, but since killing the primary track is also in user responsibility, this should probably be as well)
• Does this flag need to do something else, other than keeping track of the fact that a particle has been fast simulated? (I don't think it does, but maybe others do)?

Tagging @peter-mckeown @gaede to solicit some inupt explicitly

[github-actions]

Test Results

   18 files     18 suites   6h 12m 50s ⏱️
  372 tests   372 ✅ 0 💤 0 ❌
3 278 runs  3 278 ✅ 0 💤 0 ❌

Results for commit 3268d0e.

♻️ This comment has been updated with latest results.

[peter-mckeown]

Hi @tmadlener, thanks for starting this. Here's my two cents:

• I would say splitting this into FAST_SIMULATION_TRK and FAST_SIMULATION_CALO is probably the most generic approach, although calo is currently the main use case as you say
• I think it would be good to have some way of ensuring the user does not forget to set this flag, as this could cause confusion later (in particular if full simulation was not performed with detailed mode). Whether this is best done inside DD4hep by querying if Geant4FastSimShowerModel::check_trigger is passed as you say or externally I am not sure (I assume technically there is no blocker, since it is just setting a flag based on this condition? The only case I can imagine where having the trigger inside of DD4hep is restrictive is if the user doesn't kill the primary, but I don't think that is really a valid use case- and a flag on the primary wouldn't help then anyway).
• We have previously considered trying to add some kind of 'fast bit' that would keep track of whether Geant4FastSimShowerModel::check_trigger had failed at some point in the MC lineage of a given particle (to prevent unwanted fast sim triggers). However, I think this is trying to solve a different problem and is also a lot more involved, so probably out of scope for this

[tmadlener]

Looking into the implementation of the fast simulation inside DD4hep in a bit more detail, it's not entirely clear to me where we would need to place the setting of this status. Users that implement their own fast sim model, definitely do not have access to it any longer, I think, because they only get handed the G4 quantities, but not the DD4hep wrappers around them.

[andresailer]

Maybe using G4Track::SetUserInformation https://geant4.kek.jp/Reference/11.3.2/classG4Track.html ? And then read this from the ParticleHandler?

[tmadlener]

I have added an attempt here to go via the primary map, but this doesn't seem to persist to the output (which is not currently part of the PR!).

This has several issues:

• It doesn't work
• Even if it did it probably wouldn't work correctly for non-primaries

I have also tried adding the information to the Geant4ParticleMap that is an extension of the event context. However, that only seems to be populated by the particle handler at the end of the event, so it's empty while we would like to attach something.

I could add a Geant4ParticleInformation with a custom ParticleExtension but that looks a bit overkill for just wanting to set a flag (and it would prevent adding another one by users).

Other possible options would be to hook into Geant4ParticleHandler::mark by adding another flag to the Geant4ActionSD that returns whether it's fast sim or not, but I am not entirely sure if that is as easy as I currently think it is.

Any input welcome :)