KAHIBARO
14.3. Event Selection
Table of Contents
Cuts
In event based analyses you almost never use all recorded events. Instead, you define selection criteria, usually called “cuts,” to keep events that are likely to be interesting and reject the rest. In ROOT, cuts are implemented through logical conditions on event variables and are applied while looping over events or with tools such as TTree::Draw() or RDataFrame::Filter().
A cut is any statement that evaluates to true or false for a given event. Typical examples involve kinematic quantities, detector quality flags, or reconstruction results, for example requiring a track momentum $p > 1\ \text{GeV}$, a time of flight between two values, or a valid fit status. In C++ and ROOT, cuts are simple logical expressions that use comparison operators like <, >, ==, != together with logical operators like && for “and,” || for “or,” and ! for “not.”
Cuts are often expressed as thresholds or ranges on variables. For a single variable $x$, a common pattern is a “window” cut
$$
x_{\min} < x < x_{\max},
$$
which keeps only events whose value lies between two boundaries. When several variables are involved, you combine simple cuts into more complex selections.
Important rule: A cut must be fully defined in terms of variables that exist for every event, and its logical expression must be unambiguous. Always check that your cuts do not unintentionally remove good events or keep obviously bad ones.
Operationally, you apply cuts in ROOT in two main ways. When performing a manual event loop, you place an if statement around the code that processes or fills histograms for an event. If the cut condition is not satisfied, you skip to the next event. When you use high level interfaces, such as TTree::Draw(), you pass the cut as a string expression, and ROOT internally evaluates the condition for each entry. In both cases, the effect is identical: only events that pass the cut contribute to your results.
Cuts are not only about cleaning up obviously unphysical events. They also shape the physics content of your selected sample. For example, a cut on the number of reconstructed tracks changes which processes dominate the dataset. Because of this, every meaningful analysis must document the exact cuts used, their motivation, and their impact on the remaining number of events.
There is always a trade off between purity and efficiency. Very tight cuts can give a very pure sample of the process of interest, but may throw away a large fraction of true signal events. Very loose cuts keep more signal but also more background. Good event selection tunes these cuts so that statistical uncertainties and systematic biases remain under control.
Signal regions
A central concept in event based analysis is the signal region. The signal region is the part of the multidimensional space of observables where you expect events from the process you want to study to be concentrated. By defining a signal region, you translate physics expectations into a precise set of cuts.
In simple cases, a signal region is a range in one variable. For instance, when reconstructing the invariant mass of a particle decay, you might define a mass window around the known mass value. Suppose the true mass is $m_0$ and your detector resolution on this mass is $\sigma_m$. A common choice is a symmetric window
$$
m_0 - n\sigma_m < m_{\text{reco}} < m_0 + n\sigma_m,
$$
with $n$ of order 2 or 3, which balances the fraction of true signal events retained against the amount of background contamination.
More realistic analyses define signal regions in several variables at once. For example, you can combine a mass window with requirements on transverse momentum, quality of track fits, or isolation variables. In such cases, the signal region becomes a volume in a higher dimensional space. ROOT tools let you implement this by combining multiple cut conditions into a single selection expression, and then filling histograms or computing summary quantities only for events that satisfy all parts of the definition.
Important rule: The signal region must be clearly defined before looking at the final result, to avoid tuning cuts to statistical fluctuations in the data. Changing the signal region after viewing results can introduce bias.
In practice, you typically tune the signal region using simulated signal samples or side information about detector performance, not the signal peak in the data that you will later quote as a result. Once you commit to a definition, everything that follows, from yield measurements to parameter extractions, is carried out using only events that fall into this predefined region.
Signal regions can be further subdivided. For instance, if you expect different background compositions at low and high transverse momentum, you might define several exclusive signal regions in different momentum intervals. This allows differential measurements where the same underlying process is studied under different conditions.
Another practical aspect of signal regions is reproducibility. You should always preserve a concise mathematical or logical definition of your region. In ROOT terms, this is often as simple as storing the selection string or the piece of macro code that encodes the cuts. That definition can then be reused exactly in later analyses or by collaborators who want to compare results.
Background regions
While the signal region captures where the process of interest is found, background regions are parts of the observable space that contain mainly, or ideally only, background events. They are essential because they allow you to estimate how many background events contaminate your signal region and how background behaves as a function of relevant variables.
The simplest example of a background region is a sideband in a mass distribution. If the signal appears as a peak around $m_0$, you can choose two windows, one below and one above the peak, that are far enough from $m_0$ so that signal contribution is negligible, but close enough that the background level and shape are similar to those under the peak. These sidebands form your background regions. Their definition again uses cuts, such as
$$
m_{\text{low,1}} < m_{\text{reco}} < m_{\text{low,2}}, \quad
m_{\text{high,1}} < m_{\text{reco}} < m_{\text{high,2}}.
$$
In more dimensions, you can define control regions where one or more variables are chosen so that signal is strongly suppressed but the dominant background processes remain. A classic pattern is to invert or relax a particular cut that enhances signal purity. For example, if your signal has a high particle identification score, you can define a background region by selecting low identification scores while keeping other cuts identical. That region is then used to test and tune your background model.
Important rule: Background regions should be constructed to resemble the signal region with respect to background composition and detector response, while being as free of signal as possible.
In ROOT workflows, background regions are implemented with their own selection expressions. You might, for instance, fill one histogram from events passing the signal region cuts and another from events passing a sideband selection. By comparing these, and possibly normalizing them using the relative widths or event counts in the regions, you can estimate the background contribution in the signal region. This kind of data driven background estimation helps reduce dependence on simulation and can make your results more robust.
Background regions also serve as validation tools. Before trusting a fit or a model in the signal region, you check its agreement with data in background dominated areas. Discrepancies there can reveal mis modeled detector effects, incorrect shapes, or missing components. Since background regions ideally contain no signal, tensions between data and prediction in those regions clearly point to a problem in the background description.
Finally, both signal and background regions are part of a larger strategy of categorizing events. Careful design of these regions, with clear, reproducible cut definitions implemented in ROOT, lies at the core of any reliable event based analysis, and it directly shapes the statistical and systematic uncertainties of your final results.
Views: 12