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

Ways to store multiple event weights #242

Closed
tmadlener opened this issue Dec 6, 2023 · 2 comments · Fixed by #254
Closed

Ways to store multiple event weights #242

tmadlener opened this issue Dec 6, 2023 · 2 comments · Fixed by #254
Labels
enhancement New feature or request

Comments

@tmadlener
Copy link
Contributor

Some event generators produce more than one event weight. However, currently the EventHeader only has one weight so storing multiple event weights is not easily possible. I had a brief discussion with @selvaggi about different ways to this and some considerations to be taken into account. The possibilities are

  1. Store the weights as UserDataCollection. This would require no real changes to EDM4hep or podio, but would require the introduction of a new convention for naming this collection.
  2. Add a VectorMember of double to the EventHeader. This would potentially require some schema evolution developments for podio (needs confirmation) but would not require any new naming convention.
  3. Store the weights as key - value pairs in the Frame parameters. This would also not require any changes to EDM4hep or podio, but would make the weight values rather hard to obtain with plain root / RDataFrame means.

The first two options would also require to store the names of the weights separately. However, since those are the same for all events, they could just be put into the file level metadata for which all the necessary pieces are already in place. The one thing that would then be necessary in, e.g. FCCAnalyses would be to construct a mapping of the names to the indices in either the UserDataCollection or the VectorMembers for the corresponding weight. That should be fairly straight forward we think as it only needs to be done once, and can be entirely hidden from the user, unless @kjvbrt does not agree there.

Our favorite currently would be to go with option 2, i.e. an additional VectorMember in the EventHeader as it seems to be the most stable and natural solution.

As a side note: LCIO achieves this with its version of option 3.

Potentially related: #241

@tmadlener tmadlener added the enhancement New feature or request label Dec 6, 2023
@kjvbrt
Copy link
Contributor

kjvbrt commented Dec 19, 2023

Hi, would it be useful to have weight for the global weight of the event and a weights vector?

For now, I like the second option as well. It provides clear place for the weighs and allows one to easily write a FCCAnalyses defines quickly if he/she knows which specific weight in the vector of weights needs to be used.
However, I'm not sure how to provide the access to the weight names in this case in FCCAnalyses -- needs some experimentation.

Storing weights as key/value pairs would be nicer, but then why not put the whole event header into Frame parameters.

RDataFrame comment: How to combine weight vector with .Vary().

@selvaggi
Copy link

@kjvbrt, indeed it would be useful to have them separate because not everyone is interested in weight variations. However usually when weight variations are defined it is standard practice to store the global weight in the first position as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants