Project

General

Profile

Feature #11118

SelectEvents setting should respect filters by default

Added by Christopher Backhouse over 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
12/10/2015
Due date:
% Done:

0%

Estimated time:
Scope:
Internal
Experiment:
NOvA
SSI Package:
Duration:

Description

We've been bitten a few times by missing SelectEvents lines in our ROOTOutput module. The effect of this is that everything runs normally, and everyone assumes that the events we tried to filter out are gone, but when one runs over the output file downstream modules still see those events, but with downstream products sometimes missing (because their producers followed the filter). In a production setting that isn't noticed either (the exceptions just skip the events) and then interactively, 6 months after that, the exceptions freak someone (me) out and lead to a long and unproductive discussion on the mailing list.

I think we'd be in favour of changing the default so that an output module never tries to write Events that any Filter in the path has rejected. Obviously there would be a switch to revert to the old behaviour. I'm not sure if there's a complication with multiple paths here. Maybe refusing to run in that case until an explicit SelectEvents line was provided would be the best compromise there.

I can imagine different experiments have different opinions on this. Then again maybe not. The question of allowing global defaults to be configured differently for the different experiment's executables (nova etc) has come up before. I understand that it might make it harder to debug issues that depend on those switches, but it would make satisfying everyone in situations like this much easier.

History

#1 Updated by Rob Kutschke over 3 years ago

For what it's worth, Mu2e likes the current behaviour: output modules write all events unless otherwise directed.

#2 Updated by Christopher Green over 3 years ago

An output module is not attached to a path, so we wouldn't know which path to use in the case of multiple. The selectEvents mechanism is in fact how an output module or analyzer is associated with a path, and the logic allowed is much more flexible than a 1:1 relationship between an end-path module and a trigger path.

Put simply, except in the case of precisely one path and precisely one output module, the "default" behavior is difficult or impossible to discern.

#3 Updated by Christopher Backhouse over 3 years ago

How about "if no path allowed the Event through to the end, don't write it to the output file"?

#4 Updated by Christopher Backhouse over 3 years ago

Or, "if any path contains an EDFilter, a SelectEvents line is mandatory"?

#5 Updated by Kyle Knoepfel over 3 years ago

  • Status changed from New to Feedback

This is being discussed on the art mailing lists.

#6 Updated by Adam Lyon over 3 years ago

Like Mu2e, g-2 likes the current behavior. I see your rationale for your feature request and your desire to make the system more resistant to mistakes. But I think this change makes the system harder to understand and would lead to new and perhaps more subtle mistakes.

#7 Updated by Kyle Knoepfel almost 3 years ago

  • Status changed from Feedback to Closed

Closed due to stakeholder agreement.



Also available in: Atom PDF