19.7. Coincidence Output
Table of Contents
Detector positions
Coincidence output in GATE collects information from pairs of singles that satisfy the coincidence criteria of the digitizer, for example the coincidence time window. For PET and other coincidence based systems, one of the most important parts of this output is the position of the two detectors that recorded the photons.
In a typical GATE coincidence output, each coincidence entry contains positions for both members of the pair. Depending on your digitizer configuration and output format, these can appear either as explicit coordinates for each hit, such as $(x_1, y_1, z_1)$ and $(x_2, y_2, z_2)$, or as detector indices that you can convert to positions using the scanner geometry definition.
If you write coincidence data to ROOT, you commonly get branches that represent the positions of the two detectors or interaction points. A simplified logical view is:
| Quantity | Meaning |
|---|---|
| pos1_x, pos1_y, pos1_z | Position of the first coincidence member |
| pos2_x, pos2_y, pos2_z | Position of the second coincidence member |
These positions are expressed in the global simulation coordinate system, using the standard GATE units for length. When you configured your simulation, you decided on units such as millimeters or centimeters. In the coincidence output, the numeric values follow that convention. If your scanner is built from repeated volumes, the detector indices that appear in the output can be mapped back to physical positions using your geometry construction functions.
Detector positions are essential for constructing lines of response in PET simulations, and for any analysis that needs the spatial relationship between the two detection points. You can interpret each coincidence as a pair of 3D vectors in space, which you will later use to compute lines, midpoints, or angular distributions.
Always verify which coordinate system and length unit your coincidence output uses before analysis. Mixing coordinate systems or units will lead to incorrect lines of response and wrong geometrical interpretations.
Energies
Coincidence output also includes the measured energies of the two detector events. These values are the result of the full digitizer chain, including energy summation and any blurring or thresholds you configured.
In a typical coincidence record you will find one energy value for each member of the coincidence, for example:
| Quantity | Meaning |
|---|---|
| energy1 | Measured energy of first coincidence event |
| energy2 | Measured energy of second coincidence event |
The energies are stored in the same energy units used elsewhere in your GATE simulation, usually keV or MeV. If you have applied an energy window in the digitizer, for example a PET photopeak window around 511 keV, only coincidences that satisfy those selection criteria appear in the coincidence output. If you have not applied a strict window, you may see a wide range of energy values, including scattered and random events with lower energies.
For PET analysis, you often use the energies to classify coincidences, such as distinguishing true, scattered, and random events by checking whether both energies are within a chosen energy window around the photopeak. In some studies you may also look at the sum or difference of the two energies, or at energy spectra conditioned on other variables such as time difference or detector position.
Check the energy units and the applied energy windows in your digitizer before interpreting coincidence energies. Misinterpreting keV as MeV, or ignoring thresholds, can completely distort scatter and photopeak analysis.
Times
Coincidence output records timing information so you can determine whether two singles belong to the same coincidence and perform time of flight analysis if applicable. For each coincidence entry the output contains at least one time for each event, typically the measured detection times after any timing blurring you configured in the digitizer.
A typical coincidence record includes:
| Quantity | Meaning |
|---|---|
| time1 | Detection time of the first coincidence event |
| time2 | Detection time of the second coincidence event |
These times are stored in the simulation time units used by your GATE configuration, such as nanoseconds or microseconds. The coincidence sorting uses the difference between these times and the configured coincidence timing window to decide which pairs to record as coincidences.
For non TOF PET systems, you might only need the time difference between the two events, but GATE still stores individual times which allow you to reconstruct the difference yourself. For TOF PET simulations, the time difference $\Delta t = t_1 - t_2$ is a key quantity, because it lets you estimate where along the line of response the annihilation took place. This position estimate is proportional to the time difference, divided by the speed of light, in the medium.
A simple relationship is:
$$
\Delta x = \frac{c \, \Delta t}{2}
$$
where $\Delta x$ is the position offset along the line of response, $\Delta t$ is the detection time difference, and $c$ is the speed of light.
Timing information is also useful when you study random coincidences, time based count rates, or time dependent acquisition protocols where activity or geometry changes during the simulation.
Always confirm the time units of your coincidence output and the exact definition of $t_1$ and $t_2$ before computing time differences or TOF positions. Using inconsistent units or sign conventions will give incorrect localization along the line of response.
Event information
Beyond positions, energies, and times, coincidence output contains event level identifiers and flags that help you interpret and classify coincidences. These pieces of information link coincidences back to the underlying physics events and to the singles that created them.
Typical event information in coincidence output includes:
| Quantity | Meaning |
|---|---|
| eventID1, eventID2 | Original event identifiers of the two singles |
| runID | Identifier of the simulation run |
| sourceID | Identifier of the primary source or source index |
| globalEventID | Combined or coincidence level event identifier |
The exact naming can vary with the digitizer and output configuration, but the idea is always that you can trace which primary event generated each side of the coincidence. This is particularly important when you want to classify coincidences as true, scattered, or random based on the relationship between the two events, and when you study performance quantities that depend on the primary origin of the photons.
In many PET simulations, additional labels may be stored in the coincidence output, such as flags indicating whether a coincidence is geometric, accepted by energy and timing windows, or tagged by the simulation as true, scatter, or random. These flags are produced when you enable detailed classification options and are extremely useful for performance studies, sensitivity analysis, and validation.
Event information is also essential when combining results from multiple runs or multiple threads. Using run and event identifiers, you can merge coincidence data sets, sort them, or filter them according to particular conditions, such as selecting only coincidences from a specific source or from a certain time interval during the acquisition.
Do not assume the meaning of event identifiers and classification flags in coincidence output. Always check your digitizer configuration and documentation to understand how GATE defines and fills each event field, especially when you perform true, scatter, and random separation or merge data from multiple simulations.
Views: 10
KAHIBARO