Proposal for a PseudoParticle type

[ruse-traveler]

One point that came up in the July 2024 UGM eID/Reconstruction Workfest was the need for an additional datatype (or datatypes) to improve the flow of information between different stages of our eID and PF workflows.

Describe the solution you'd like
For example, a new "PseudoParticle" type which collects the relevant tracks, clusters, and PID information into a single type would help with:

1. Ensuring that both our eID and PF remain modular; and
2. Allowing more easily for future extensions of the algorithms or workflows.

In effect, this type would function for particles the same way that edm4eic::ProtoCluster functions for clustering int the calorimeters, factorizing the "connection/arbitration" and "regression" stages of both eID and PF. @tylerkutz Authored a possible implementation of such a type:

edm4eic::PseudoParticle:
  Description: "Detector response from particle of unknown PID"
  Author: "T. Kutz, D. Anderson, S. Li"
  OneToOneRelations:
    - edm4eic::Track               track        // reconstructed track... other relations matched to this
   OneToManyRelations:
    - edm4eic::Cluster             ecalClusters // ECAL clusters matched to this track
    - edm4eic::Cluster             hcalClusters // HCAL clusters matched to this track
    - edm4eic::PMTHit              pmtHits      // PMT hits matched to this track
    - edm4eic::CherenkovParticleID cherenkovPID // Cherenkov PID matched to this track
    - edm4eic::RingImage           ringImages   // Ring Image clusters matched to this track

Describe alternatives you've considered
Alternatively, we might follow the edm4hep authors, who recently changed the direction of their PID-Reconstructed Particle relations. This would place the step of connecting PID hypotheses to reconstructed particles at the final "regression" stage and might remove the need for a PseudoParticle-like object.

Additional context
This falls into the Reconstruction WG's eID/PFA development program.

[ruse-traveler]

There have been multiple discussions on this topic in the Reconstruction WG. See the slides, notes, and minutes attached to the following indico pages:

• Aug. 27th Reco Meeting;
• Sep. 16th Reco Meeting; and
• Oct. 14th Reco Meeting.

Based on these discussions, the initial PseudoParticle has been factorized into 3 types:

1. A simple TrackClusterAssociation.
2. A ChargedParticleCandidate. and
3. A NeutralParticleCandidate.

[1] TrackClusterAssociation

This is very nicely filled by edm4eic#52.

[2] ChargedParticleCandidate

A possible implementation of the charged particle candidate could be:

## A charged particle candidate
edm4eic::ChargedRecoParticleCandidate:
  Description: "Candidate charged reconstructed particle"
  Author: Tyler Kutz, Derek Anderson, Shujie Li
  OneToOneRelations:
    - edm4eic::Track      track        // reconstructed track... other relations are matched to this
  OneToManyRelations:
    - edm4hep::ParticleID particleIDs  // associated particle IDs
    - edm4eic::Cluster    ecalClusters // ECAL clusters matched to this track
    - edm4eic::Cluster    hcalClusters // HCAL clusters matched to this track
  VectorMembers:
    - float               ecalWeights  // weights of matched ecal clusters
    - float               hcalWeights  // weights of matched hcal clusters

[3] NeutralParticleCandidate

A possible implementation of the neutral particle candidate could be:

## A neutral particle candidate
edm4eic::NeutralRecoParticleCandidate:
  Description: "Candidate neutral reconstructed particle"
  Author: Tyler Kutz, Derek Anderson, Shujie Li
  OneToManyRelations:
    - edm4hep::ParticleID particleIDs  // associated particle IDs
    - edm4eic::Cluster    ecalClusters // associated ECAL clusters
    - edm4eic::Cluster    hcalClusters // associated HCAL clusters
  VectorMembers:
    - float               ecalWeights  // weights of associated ecal clusters
    - float               hcalWeights  // weights of associated hcal clusters

[ruse-traveler]

For further context, here's a schematic illustration of the wiring surrounded the above types. The lines with a question mark indicate that these assume PID signals will be merged somehow into a combined PID hypothesis before these factories.