Conceptually there is a different filter for each class of events: function events,
messages and collective operations. During analysis the event is recognized when the
expression is matched.
The behavior of a filter is determined at the time of its creation. A filter
continues filtering until it is changed, even when the thread groups or function
groups that it references are changed. Events are treated as belonging to these
groups based on the state of the groups at the time the filter was first
If several events are merged as described in the Level of Detail section, then the merged
event is tagged if at least one of the singular events is tagged.
Therefore you can use tagging in particular together with the Qualitative
Timeline Chart to find events matching a certain criterion. If a single event out
of billions matches the criteria of the tag filter, you see a highlighted peak in
the Qualitative Timeline Chart that indicates where to zoom into the trace.
If an event is suppressed by filtering then the effect is as if it were never
written to the trace file. This is relatively easy to understand for messages and
However, if a filter is designed in the way that it suppresses MPI and enables
all other functions to pass, then after filtering the Event Timeline looks as if
MPI was not called. It looks as if the thread was in the calling function instead
of being in MPI. The same is true for the call tree and the call graph of the
What happens if there are functions A, B and C in the trace where A calls B and B
calls C and you filter B out? It appears as if A had called C directly. This is
quite different from choosing a function aggregation that does not cover B,
because that shows the function group other (
) wherever B was shown before. Filtering and
Aggregation are independent.