KAHIBARO
14.1 Understanding Event Data
Table of Contents
Event structure
In event based analysis you treat your dataset as a sequence of individual events. An event is one occurrence of your experimental process. In a collider experiment it is one beam crossing that produces particles in the detector. In a nuclear physics setup it can be one decay, one interaction in the target, or one trigger signal from the electronics. The essential idea is that each event can be analyzed independently, then all events are combined statistically.
ROOT represents this structure very naturally with TTrees. Each entry of a TTree corresponds to one event. All the quantities you store for that event are grouped into branches. When you loop over the entries of a TTree, you are effectively looping over events. This one entry, one event mapping is the backbone of event based analysis in ROOT.
Inside one event you usually have different kinds of information. There can be global information that belongs to the whole event, such as the event number, the run number, or a trigger flag. There can also be repeated information, such as a list of hits in a detector layer, or a list of reconstructed tracks. This is why branches often store arrays or std::vector objects, because a single event may contain a variable number of such objects.
It is common to distinguish between raw events and reconstructed events. Raw events contain information very close to what the detector electronics recorded. Reconstructed events contain higher level quantities that have been derived from the raw signals, such as particle momenta or track parameters. Both levels can be stored in ROOT TTrees. For analysis, you often use reconstructed events, but sometimes you need to go back to raw quantities to understand detector effects.
Event structure is also influenced by how the experiment is organized. Data is usually grouped into runs, which are periods with stable detector conditions. A run can contain millions of events. You can either store each run in a separate ROOT file or chain several files together using TChain. In both cases the logical idea remains the same. Your analysis works event by event.
In event based analysis, one TTree entry corresponds to one event, and all event quantities are stored in branches. Keeping this one to one mapping clear prevents many logic errors in your analysis.
Detector measurements
Every event begins with detector measurements. These are the direct responses of the detector hardware to what happened physically during the event. At the lowest level, detectors record signals such as charge, voltage, time, or light intensity. These signals are converted by electronics into digital values. Such low level numbers are what we call raw measurements.
Different detector components provide different types of measurements. A tracking detector records where charged particles passed, usually as hits with position information. A calorimeter records deposited energy as ADC counts that later can be calibrated to physical energy units. A time of flight detector records the time difference between a start signal and the particle arrival, which you can convert into a velocity. In nuclear spectroscopy, detectors record pulse heights related to particle or gamma ray energy, and times related to decay processes.
The data acquisition system collects all detector measurements that belong to the same physical event and tags them with a common event identifier. From the analysis perspective, this bundling is extremely important. It guarantees that all measurements within one event are causally related to the same physical occurrence. ROOT then stores these measurements in branches associated with that event entry.
Before these measurements can be used for physics analysis, they need calibration and sometimes alignment. Calibration converts raw ADC counts or times into physical units like MeV, ns, or mm. Alignment corrects geometrical positions of detector elements. These steps are usually applied early in the reconstruction chain, and the calibrated quantities are stored in TTrees as well. Even if your TTree already contains calibrated values, it is useful to remember that they originated from detector measurements with finite resolution and possible systematic shifts.
Detector measurements often contain noise and inefficiencies. Not all real particles are detected, and some recorded signals may not correspond to real particles. Your analysis must take this into account, sometimes by applying quality cuts directly on raw or near raw quantities. ROOT helps here by allowing you to combine such cuts with event based histograms and selections.
Detector measurements are raw or calibrated signals directly from the hardware. They always have finite resolution, possible noise, and efficiency losses, which you must remember when interpreting event level quantities.
Event variables
Event variables are the numbers you actually use in your physics analysis. Each event has a set of variables that describe it, based on the detector measurements and the reconstruction algorithms. In ROOT, each such variable is typically stored as a branch of a TTree. When you read an entry, ROOT fills your C++ variable with the value for that particular event.
There are simple, scalar event variables. Examples include event_id, run_id, trigger bits, total reconstructed energy in the event, number of tracks, missing transverse energy, or time since the start of the run. These are suitable for simple branches of types like int, float, or double. They provide a quick characterization of the event and are often used for fast selections.
There are also structured event variables that come as lists or arrays. For instance, in one event you might have several tracks. Each track has its own momentum, charge, and quality flag. In ROOT TTrees this often appears as a branch that stores a std::vector<float> or std::vector<double>, for example one vector for all track transverse momenta and another for pseudorapidities. The length of these vectors can change from event to event. That is how you represent variable multiplicity.
Event variables can be either measured or derived. Measured variables are directly connected to detector quantities after calibration, such as a hit position or a cluster energy. Derived variables are computed from one or several measured quantities. Examples include invariant mass of two particles, transverse momentum computed from momentum components, or an angle between two tracks. In ROOT based analysis, you frequently create such derived variables in your event loop or with RDataFrame, and sometimes store them back into new TTrees or into histograms directly.
It is useful to classify event variables by their analysis role. Some variables are selection variables, used to decide whether an event passes a given cut, for example energy > 1 GeV or number_of_hits >= 5. Some are control variables, used to monitor detector performance or validate the analysis. Others are final observables, the quantities that eventually go into your plots and physics results, like a mass spectrum, a cross section as a function of angle, or a decay time distribution.
When working with ROOT, your event based analysis usually follows a pattern. You read event variables from one or more TTrees, apply selection conditions on these variables, compute any new variables you need, and fill histograms or graphs. Understanding exactly what each event variable represents, and whether it is measured or derived, is essential to avoid misinterpreting your results.
Event variables are per event quantities stored in TTree branches. They can be simple scalars or variable length vectors, and can be measured directly or derived from other variables. Knowing their origin and meaning is crucial for correct event selection and analysis.
Views: 13