Make user particle handler extensible

[murnanedaniel]

It is noted in the library that the ParticleHandler is not extensible currently:

DD4hep/DDG4/python/DDSim/Helper/ParticleHandler.py

Lines 117 to 120 in 3466ee7

	def setupUserParticleHandler(self, part, kernel, DDG4):
	"""Create the UserParticleHandler and configure it.
	FIXME: this is not extensible at the moment

I am trying to add a more truth-heavy handler here: Geant4FullTruthParticleHandler, which then needs to be handled by the python handler. Currently my solution is here:

if self.userParticleHandler not in ["Geant4TCUserParticleHandler", "Geant4TVUserParticleHandler", "Geant4FullTruthParticleHandler"]:
      logger.error("unknown UserParticleHandler: %r" % self.userParticleHandler)
      exit(1)

    if self.userParticleHandler in ["Geant4TCUserParticleHandler", "Geant4FullTruthParticleHandler"]:
      user = DDG4.Action(kernel, "%s/UserParticleHandler" % self.userParticleHandler)
      try:
        user.TrackingVolume_Zmax = DDG4.tracker_region_zmax
        user.TrackingVolume_Rmax = DDG4.tracker_region_rmax
etc.

But this is clunky. I would be very happy to tweak the handler to be extensible, if someone could describe what is in mind for this?

I guess the particle handler could be defined as a config, e.g.

sim.part.userParticleHandler = {"handler": "Geant4TCUserParticleHandler", "user.TrackingVolume_Zmax": "DDG4.tracker_region_zmax", etc.}

Although this is still not completely extensible.

[andresailer]

Hi @murnanedaniel

What will your particle handler do? And what kind of configuration do you have in mind?
Will you submit this as a PR to DD4hep, or do you want to keep it in your own library?

The most extensible way would be for users to define their own setup function that is called from the setupUserParticleHandler function.

if callable(self.userParticleHandler):
   user = self.userParticleHandler(kernel, DDG4)
   part.adopt(user)

And leave the current implementation as is.

e.g. like

DD4hep/DDG4/python/DDSim/Helper/Physics.py

Line 164 in 3466ee7

def setupUserPhysics(self, userFunction):

or

DD4hep/DDG4/python/DDSim/Helper/OutputConfig.py

Line 75 in 3466ee7

def userOutputPlugin(self):

But that would only make sense if the handler does not live in DD4hep.

[murnanedaniel]

@andresailer
The particle handler retains truth information of:

• Particles created in the tracker if they leave a hit OR are above energy threshold
• Particles entirely in the calo if they leave a hit AND are above energy threshold

But of course every project may have slightly different requirements of how much truth they would like to retain. So I'm not necessarily intending to merge this into DD4hep (unless it is broadly useful).

I think your proposal of the setup function in setupUserParticleHandler would be best. Although it's not totally obvious to me what the suggested workflow would then be. Would you build the particle handler somehow standalone and point to it with the custom function?

[andresailer]

Would you build the particle handler somehow standalone and point to it with the custom function?

Yes, if you don't want to merge it into DD4hep, what else would you do?

But in fact, there is no difference for the implementation of the setup function whether you have it in DD4hep or not, since the plugin system will just find it where ever it comes from.

The function must have a line like

 user = DDG4.Action(kernel, "Geant4FullTruthParticleHandler/UserParticleHandler")
 #...
 return user

Or something else if the plugin is not called Geant4FullTruthParticleHandler .

But for tools inside DD4hep, I would not make users write a function in the first place since that would be cumbersome, but rather add the configuration directly.

[MarkusFrankATcernch]

Before doing here premature hacks, it has to be seen that this architecture was implemented more than
10 years ago based on the requirements from SLIC and the CLICDP simulation experiences.
The requirements may have slightly changed since...

If the particle handler is supposed to be extended I think we should perhaps think a bit about the interface
and the calls from the Geant4ParticleHandler.
We could e.g. implement callbacks to support the debugging of sub-detectors during hit handling.
Such callbacks would also allow to collect additional information about a track and subsequently take a
more fine-grained decision in the callback to Geant4UserParticleHandler::keepParticle(Particle& particle)
including the use of the user-bits in the Particle members.