Proposal for a Jet Type

[ruse-traveler]

Since edm4hep has no jet-specific data type (e.g. see the discussions here and here), we opted to use edm4eic::ReconstructedParticle to hold the jet kinematic information when implementing jet reconstruction in EICrecon. This has obvious shortcomings:

• Jets are extended objects (have an area), and there are no fields reflecting this in ReconstructedParticle;
• Jets also necessarily pick up background, which is also not reflected in ReconstructedParticle;
• And this also introduces conceptual confusion: while there is a correspondence between jets and the partons that produce them, it's not necessarily one-to-one, and concepts like "jet charge" carry meanings distinct from their particle counterparts.

Describe the solution you'd like

The FastJet PseudoJet provides a very nice starting point. A possible way something similar could be implemented in our data model is like so:

  edm4eic::Jet:
    Description:  "A reconstructed jet, inspired by the FastJet PseudoJet"
    Author: "Joan Jet"
    Members:
      - uint32_t nCst // number of constituents in jet
      - float area // jet area [sr]
      - float energy // jet energy [GeV]
      - float bkgdEnergy // background energy density * area [GeV]
      - edm4hep::Vector3f momentum // jet 3-momentum [GeV]
    OneToManyRelations:
      - edm4eic::Jet jets // jets that have been combined to form this jet
      - edm4eic::ReconstructedParticle constituents  // constituents of the jets

Note that there are a couple of intentional design choices here:

• Constituents are constrained to be reconstructed particles only;
• And while access to the constituents is preserved through the one-to-many relations, there are no fields for jet substructure/shapes like zg or ptD.

The former point places jet reconstruction at the very end of our reconstruction workflow; and the latter point is due to the fact that quantities like zg are often highly analysis-dependent, are frequently algorithmically complex, and there are a lot of them. Personally, my opinion is that these would be better served as functions of jets that users could call during downstream analysis.

Also note that the jets one-to-many relation could be used to indicate things like sub-jets.

Describe alternatives you've considered

An alternative approach could be to design a "jet information" type that runs parallel to the jets and stores all of the information not captured by ReconstructedParticle.

[veprbl]

Looks good to me. Please don't use abbreviations (nCst, bkgd). We don't need to store number of constituents separately, as we know the size of OneToMany relations.

[ruse-traveler]

Fair point!