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
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
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.
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.
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.
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().
@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.
Some event generators produce more than one event weight. However, currently the
EventHeader
only has oneweight
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 areUserDataCollection
. This would require no real changes to EDM4hep or podio, but would require the introduction of a new convention for naming this collection.VectorMember
ofdouble
to theEventHeader
. This would potentially require some schema evolution developments for podio (needs confirmation) but would not require any new naming convention.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 theVectorMembers
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 theEventHeader
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
The text was updated successfully, but these errors were encountered: