Displaced DM Decay Primary Generator

[tomeichlersmith]

Is your feature request related to a problem? Please describe.
The current best option for simulating displaced DM decays is three stages.

1. Have MadGraph generate the DM and their decays (i.e. something like e N -> e N DM and then DM -> e+ e-)
2. Split this output LHE into two LHEs: one containing the production of the DM (e N -> e N DM) and one containing its decay (DM -> e+ e-). At this point, you would also determine where the production happens and where the decay happens (probably sampling from some probability distribution so that the decay happens at different lengths). You can also include a time difference between them.
3. Give both of these LHEs to the simulation as two separate generators. Geant4 will then do the simulation with both of them at their specified time difference.

This solution has been implemented by folks at UVA. https://github.com/mrsolt/uva-ldmx/tree/main/visibles

Describe the solution you'd like
I think we could avoid the intermediate LHE files pretty easily. The sampling of decay lengths is a rather simple procedure and we already have an LHEReader for the LHEPrimaryGenerator. I think implementing a DisplacedDecayGenerator which would read in the single LHE file from MadGraph and then (with some configuration parameters) pick-out the DM and the decay particles, sample a decay length and place the decay particles at the correct position and time relative to the DM. We could also look into manually setting the endpoint of the DM since it has no other processes.

Describe alternatives you've considered
The alternative implemented by UVA and already functional with the current ldmx-sw is functional and physically appropriate. I just find it difficult to maintain and share.

[EinarElen]

Geant4 has a feature that lets you "pre-assign" decay products to particles. Would that be helpful for this? If you use this, you don't need to calculate the endpoint yourself, you can just let Geant do that

[tomeichlersmith]

That would be incredibly helpful, I was planning on just doing that manually.

[tomeichlersmith]

From these slides, it sounds like we need to define a child class of G4VExtDecayer.

Or we use G4PrimaryParticle's SetDaughter and SetNext. Although, I don't see a method for defining the decay length in this case.

[EinarElen]

That's mixing up two things! The pre-assigned decay products are a property of G4DynamicParticle and it is a public method. When G4Decay runs, it will prioritize any pre-assigned products. G4VExtDecayer is a fallback for when neither pre-assigned products or regular decay tables aren't available.

Regarding lifetime, I think the easiest would be to just make a particle definition for the DM particle with an average lifetime. But there is also a "pre-assigned lifetime" for dynamic particles you can use

[EinarElen]

I think the reason for most documentation talking about primary particles is just... LHC bias. Where other than in the primary collision would you ever create weird particles

[tomeichlersmith]

I'm going to mark this as closed. Users can either use the pre-processing method like linked above or utilize the support for visible decay written into G4DarkBreM introduced in #1386