Refinement of relations between Vertex and ReconstructedParticle

[tmadlener]

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 a ReconstructedParticle (associatedParticle) and the ReconstructedParticle has an association has a one-to-one relation to a Vertex (startVertex):

Vertex relations:

EDM4hep/edm4hep.yaml

Lines 563 to 564 in bd9f450

	OneToOneRelations:
	- edm4hep::ReconstructedParticle associatedParticle // reconstructed particle associated to this vertex

ReconstructedParticle relation:

EDM4hep/edm4hep.yaml

Lines 591 to 596 in bd9f450

	OneToOneRelations:
	- edm4hep::Vertex startVertex // start vertex associated to this particle
	OneToManyRelations:
	- edm4hep::Cluster clusters // clusters that have been used for this particle
	- edm4hep::Track tracks // tracks that have been used for this particle
	- edm4hep::ReconstructedParticle particles // reconstructed particles that have been combined to this particle

The rationale in LCIO (where this originates from) was that the associatedParticle is the incoming particle that decays at the Vertex it is attached to and that the particles that are attached to that ReconstructedParticle are the outgoing particles from the vertex (i.e. the decay products). This has some (arguably partially biased by personal preferences) drawbacks:

• It's not entirely intuitive, since one could expect so simply get all the decay products form the vertex directly
• More importantly it requires that the vertex and the associated particle are created within the same algorithm (in the mutability concept of EDM4hep)
• There is no easy way to refit the particles that contribute to a Vertex with different hypothesis (e.g. in B-meson decays where different combinations of charged particles might be tried, although that might be less of a concern with track level PID).

An alternative approach would be to have the following Vertex (relation) definition

edm4hep::Vertex:
  # all the rest
  OneToManyRelations:
    - edm4hep::ReconstructedParticle particles // The decay particles forming the vertex

and a slightly changed ReconstructedParticle

edm4hep::ReconstructedParticle:
  # all the rest
  OneToOneRelations:
    - edm4hep::Vertex decayVertex // The vertex where this particle decayed

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 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 a VtxColl and a HLRecos 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)

In this case the two solutions are more or less equivalent, the major difference being the access to the decay particles from the high level reco particles:

current	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 a VtxColl (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 the Vertex. 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 this

current	proposed
hlReco.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

• Staying with the current proposal would require no work
• Switching to a different approach would require work in the EDM4hep - LCIO converters (potentially with some heuristics to deal with the differences)
• Both approaches can be made effectively equivalent in what they can be made to represent (as far as we have thought this through) . The major difference being the potential need for intermediate collections
• Filling the decay products only in the Vertex would be a convention rather than a strict requirement (as also touched on in the cases above)

Potentially even further reaching proposals

• Remove the relation to ReconstructedParticle(s) entirely from the Vertex, effectively making it a container only for fit quality and position information.
• Absorb the position information from the Vertex into the ReconstructedParticle, similar to the situation on the MCParticle side

Both of these would require quite a bit of conceptual work especially in the conversion.

[gaede]

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.

[tmadlener]

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.