Feature request: data type for storing jet parameters

[wdconinc]

There is no dedicated data type for jets or jet reconstruction parameters. It appears that reconstructed jets are stored in ReconstructedParticle collections (which in my opinion should stay that way), but that does not allow for storing the following information about jets:

• jet area
• jet cone
• ...

Possible implementation could:

• additional fields in ReconstructedParticles (not so great)
• parallel collection with one-to-one relation back to ReconstrucedParticles

Prior art could be seeing what fastjet produces in its most general approach.

Tagged for input: @ruse-traveler

[tmadlener]

Depending on the amount of information that you want to store along side a podio::UserDataCollection (documentation still using the EventStore unfortunately) that runs alongside the collection could be useful. That becomes a bit cumbersome if there is more than just one or two pieces of additional information though given the current limitations of what you can store in that.

In LCIO the parameters field in the ParticleID was frequently (ab)used for cases like this, as that essentially gives you a "free" vector<float> and a way to easily attach it to ReconstructedParticle. However, I would like to avoid that practice in EDM4hep if possible, as it is arguably just a UserDataCollection with extra steps and no real benefits (other than the "proper" relation to the ReconstructedParticle)

[ruse-traveler]

Hi @wdconinc and @tmadlener, I definitely agree that the actual jet should be kept in the ReconstructedParticle class, and that we definitely should avoid abusing the ParticleID field (that strikes me as a good way to confuse users down the line 😝).

A UserDataCollection would probably work for the (very) near term as we do intend to add only 1 or 2 additional pieces of information alongside the ReconstructedParticle class. However, I do see the amount of information growing very quickly as we refine our studies -- e.g. we'll need to store jet-by-jet information on the local background energy density as begin to incorporate backgrounds -- and so would advocate for an approach like Wouter suggested.

[ruse-traveler]

Hi all, apologies for the long delay in the conversation! I'd like share some ideas for a type that have been proposed in the EIC context. You can find links to the relevant issue and PR below!

• EDM4eic#88
• EDM4eic#118

In particular, I'm curious to hear if there are any common solutions the EDM4hep user base have pursued for dealing with jets inside of EDM4hep, or if there are any similar efforts to propose a jet data type for EDM4hep?

[m-fila]

Probably not the user solution you expected but in JetReconstruction.jl (Julia reimplementation of FastJet's algorithms) we have an extension for converting EDM4hep ReconstructedParticle and internal jet types