Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: data type for storing jet parameters #192

Open
wdconinc opened this issue Feb 21, 2023 · 2 comments
Open

Feature request: data type for storing jet parameters #192

wdconinc opened this issue Feb 21, 2023 · 2 comments
Labels
discussion Discussion item enhancement New feature or request

Comments

@wdconinc
Copy link
Contributor

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

@wdconinc wdconinc added the enhancement New feature or request label Feb 21, 2023
@tmadlener
Copy link
Contributor

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)

@tmadlener tmadlener added the discussion Discussion item label Feb 21, 2023
@ruse-traveler
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion item enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants