Skip to content

Conversation

@ruse-traveler
Copy link
Contributor

Briefly, what does this PR introduce?

Following the discussion in #88 , this PR introduces edm4eic::Jet. This type, inspired by the fastjet::PseudoJet, aims to represent jets in our data model in a more adequate way than edm4eic::ReconstructedParticle.

Note these 3 design choices:

  • Only edm4eic::ReconstructedParticle are allowed as constituents, which places jet reconstruction in the final stages of reconstruction,
  • No substructure quantities are represented in the type, which defers them to analyses,
  • And the one-to-many relation jets allows for either the indication of/connection to sub-jets, seed jets (which may be deployed in background-subtraction algorithms), or background jets (e.g. off-axis cones).

What kind of change does this PR introduce?

Please check if this PR fulfills the following:

  • Tests for the changes have been added
  • Documentation has been added / updated
  • Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No.

Does this PR change default behavior?

No.

@ruse-traveler ruse-traveler requested a review from a team as a code owner July 9, 2025 19:14
- uint32_t type // type of jet (0 - kt, 1 - C/A, 2 - anti-kt, ...)
- float area // jet area
- float energy // jet energy [GeV]
- float backgroundEnergy // background energy density * area [GeV]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(showing my ignorance here), I suppose the background energy density is rarely used, which is why you go for the product here instead?

Description: "A reconstructed jet, inspired by the FastJet PseudoJet"
Author: "D. Anderson"
Members:
- uint32_t type // type of jet (0 - kt, 1 - C/A, 2 - anti-kt, ...)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would propose to either

  • define static const values that define each type, or
  • clearly specify where the information of how to interpret this field can be obtained.

For the second part we have defined labels in EDM4hep that define the name of some metadata (Frame) parameter under which this information can be obtained, e.g.: https://github.com/key4hep/EDM4hep/blob/4d2242478347716d05b86c927fa6337764a5af62/edm4hep.yaml#L404

The labels are defined, here:
https://github.com/key4hep/EDM4hep/blob/4d2242478347716d05b86c927fa6337764a5af62/include/edm4hep/Constants.h#L25-L45

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants