Direction of inter-object relations

[tmadlener]

The immutability of objects that are read from file (or that are the outputs of an algorithm) is one of the most central aspects of podio generated EDMs. This requirement is/was no present in LCIO on which many aspects of the current definition build. In many of the existing workflows from LCIO it is assumed that it is possible to still add relations after the original objects have been created. For example,

• Adding ParticleID objects to existing ReconstructedParticles (and Clusters)
• Adding a startVertex to an existing ReconstructedParticle
• Updating dE/dx values after a track refit
• Refitting a track with an updated PID (and a different) mass and updating the track information after this fit

For some of these use cases it would potentially make sense to reverse the direction of the intrinsic one-to-one or one-to-many relations, e.g. Add a ReconstructedParticle to the ParticleID and remove the ParticleIDs from the ReconstructedParticle. In this way we would effectively always require that a "finished" reco particle is present to run any particle ID on top of that, and then the PID result would know for which reco particle it was run.

Similar arguments can be made for other relations, and we would probably need to decide on a case-by-case basis on what to do best.

This issue should serve as a board for summarizing discussions and potentially fleshing out some of the details.

[tmadlener]

Another point to consider here is the fact that Cluster also has a ParticleID one-to-many relation. That can potentially be removed (has to be confirmed).

[BrieucF]

Hi Thomas, following-up on last weeks discussion: it would indeed be useful to keep a link in the direction ReconstructedParticle --> ParticleID so that the 'standard' flow to loop on the particle collection and select e.g. muons remains available. Would this be possible?

[tmadlener]

It should still be possible, I agree. However, I think it will not be via checking the ParticleID of each reco particle. In principle we have a type field in the reconstructed particle that could be populated during reconstruction by the default reconstruction.

Overall, I still have to check how the current workflows map into the "new world". They will obviously be quite different, but I hope we can make them a bit better along the way. If you have any examples on how things look currently, I would be very interested in them, because then I can also have a before and after.

[tmadlener]

If all ParticleID algorithms populate their own collection, then the algorithmType member becomes effectively obsolete and could be removed as well.