Open tmadlener opened 2 weeks ago
Another option that we (BH, JMC, FG) currently would favor, is to add the reco particles to the vertex as suggested above - but have no Vertex association in the RecoParticle. If such an association is needed, it could be done in a standalone RecoParticleVertexAssociation object. The above use cases will still work - potentially w/ a bit more code to resolve the link from HLR particle to vertex.
In that suggestion, would the particles attached to the Vertex also be duplicated to the ReconstructedParticle that can be reconstructed from the ones attached to the Vertex? Should we then also add a vertex position (+ cov matrix) to the ReconstructedParticle
? Otherwise the usage of "composite" reconstructed particles in analysis could become quite cumbersome because it would then also require the usage of an additional utility to just get to the decay particles and the vertex position.
The following is a summary of discussions with @gaede and should serve as a basis for further discussion and some process documentation for the solution that is chosen at the end.
Currently the
Vertex
has a one-to-one relation to aReconstructedParticle
(associatedParticle
) and theReconstructedParticle
has an association has a one-to-one relation to aVertex
(startVertex
):Vertex
relations: https://github.com/key4hep/EDM4hep/blob/bd9f45039149781a9c54799a6d03df56b1b5ed49/edm4hep.yaml#L563-L564ReconstructedParticle
relation: https://github.com/key4hep/EDM4hep/blob/bd9f45039149781a9c54799a6d03df56b1b5ed49/edm4hep.yaml#L591-L596The rationale in LCIO (where this originates from) was that the
associatedParticle
is the incoming particle that decays at theVertex
it is attached to and that theparticles
that are attached to thatReconstructedParticle
are the outgoing particles from the vertex (i.e. the decay products). This has some (arguably partially biased by personal preferences) drawbacks:An alternative approach would be to have the following
Vertex
(relation) definitionand a slightly changed
ReconstructedParticle
This would lead to a slightly more intuitive definition (IMHO), and it would decouple the vertex finding / fitting from the creation of the incoming particle.
From a practical point of view the current definition and the proposed definition are effectively equivalent in what can be represented with them. However, the newly proposed definition allows for a slightly leaner "implementation".
Case 1: Simultaneous vertex finding / fitting and high level reco
Consider the case where we have![image](https://github.com/key4hep/EDM4hep/assets/16774861/4cebc728-fb79-4955-a550-87a51c8af381)
RecoParticles
collection that serve as inputs to the Vertex finding / fitting, which in this case also directly does some high level reconstruction. Assume that the outputs are aVtxColl
and aHLRecos
collection containing the vertices and the corresponding particles that decayed at the vertices. The situation then looks like this for the two cases (red for current, green for proposed)hlReco.getParticles()
hlReco.getDecayVertex().getParticles()
which could be made completely equivalent if we also populate the
particles
of the high level reconstructed particles, duplicating that information.Case 2: Split vertex finding / fitting and high level reco
Consider now the case where we want to split vertex finding / fitting and the subsequent high(er) level reconstruction, e.g. in order to allow multiple of these reconstructions to run. We start from the same as above: a
RecoParticles
input collection to the vertexing, this case only producing aVtxColl
(as desired output).In this case the proposed solution effectively looks like Case 1, only that we omit also producing the
HLRecos
collection. On the other hand the current implementation requires us to create an "intermediate"VtxParticles
collection that effectively only acts as a container for all the decay products, because we cannot directly attach them to theVertex
. This means that we have to effectively carry around two collections now to have access to the same information as with the new proposal. Additionally, the access to the decay products from the high level reconstructed particle looks works like thishlReco.getVertex().getAssociatedParticle().getParticles()
hlReco.getDecayVertex().getParticles()
which could again be made equivalent by populating the
particles
of the high level reconstructed particles, duplicating that information.Other considerations
Vertex
would be a convention rather than a strict requirement (as also touched on in the cases above)Potentially even further reaching proposals
ReconstructedParticle
(s) entirely from theVertex
, effectively making it a container only for fit quality and position information.Vertex
into theReconstructedParticle
, similar to the situation on theMCParticle
sideBoth of these would require quite a bit of conceptual work especially in the conversion.