You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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)
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.
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:Possible implementation could:
ReconstructedParticles
(not so great)ReconstrucedParticles
Prior art could be seeing what
fastjet
produces in its most general approach.Tagged for input: @ruse-traveler
The text was updated successfully, but these errors were encountered: