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

Adding metadata name for event filter statistics #283

Merged
merged 4 commits into from
Jun 11, 2024

Conversation

kjvbrt
Copy link
Contributor

@kjvbrt kjvbrt commented Feb 29, 2024

The vector<int> contains three values: Seen, accepted and targeted.

BEGINRELEASENOTES

  • Adding metadata name for event filter statistics.

ENDRELEASENOTES

@jmcarcell
Copy link
Member

Which filters does this apply to? And what does targeted mean? The ones for which the filter can apply?

@kjvbrt
Copy link
Contributor Author

kjvbrt commented Feb 29, 2024

This is for filters which filter events e. g. : GenEventFilter.

The targeted number of events is number of events specified in the steering or k4run -n.
If someone is reading files from a input file, there might not be enough events in the file to fulfil it.
Ideally targeted and accepted should be equal.

@tmadlener
Copy link
Contributor

What about cases where there are multiple filters? Should there be the possibility to add a filter name?

@kjvbrt
Copy link
Contributor Author

kjvbrt commented Mar 21, 2024

What about cases where there are multiple filters? Should there be the possibility to add a filter name?

Than this needs to be a vector of some struct/class (consisting of three numbers and a name for the filter)?

@jmcarcell
Copy link
Member

I think having the name is fine but we can keep discussing how it's used. Also, why is the number of events requested important? How is that information going to be used? Is it useless when you request more events than available (it only tells you that there weren't enough events)

@jmcarcell
Copy link
Member

@kjvbrt any answers to my last comment? Do we want the comment to be quite restrictive? Does one always need the number of events? Maybe we should just remove the comment entirely like the other constants?

@kjvbrt
Copy link
Contributor Author

kjvbrt commented Jun 11, 2024

My goal was to standardize also vector members, but that is probably too restrictive.

kjvbrt

This comment was marked as duplicate.

kjvbrt

This comment was marked as duplicate.

@jmcarcell jmcarcell merged commit 994ac26 into key4hep:main Jun 11, 2024
8 of 11 checks passed
@kjvbrt kjvbrt deleted the evt_filter branch June 11, 2024 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants