SelectEvents setting should respect filters by default
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.
#2 Updated by Christopher Green about 5 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.
#6 Updated by Adam Lyon about 5 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.