KAHIBARO
17.5. Detector Timing
Table of Contents
Coincidence timing
In many detector systems you are not only interested in when a single detector fires, but in whether two or more detectors fire within a short time interval. This is called coincidence timing. In Geant4 you do not build electronic coincidence modules directly, but you compute the necessary timing information from your simulated hits and events, then apply coincidence logic in your own C++ or analysis code.
A basic coincidence definition uses the hit times from different detectors. If you have two detector elements A and B, and they both record a hit in the same Geant4 event, you can obtain their times $t_A$ and $t_B$ from your hit objects. The time difference is
$$
\Delta t = t_A - t_B.
$$
In your analysis you then apply a coincidence window. For a simple two detector coincidence you might say that the detectors are in coincidence if the absolute time difference is smaller than some window $\Delta t_{\text{coin}}$ that represents your electronics and detector timing characteristics.
Coincidence condition (two detectors):
Two detector hits A and B are considered coincident if
$$
|\Delta t| = |t_A - t_B| < \Delta t_{\text{coin}}.
$$
In a Geant4 application the times $t_A$ and $t_B$ typically come from G4Step or G4Track information that you store in a G4VHit subclass. A common approach is to use the global time at the interaction point, obtained from the pre step point of the step that produced the hit:
$$
t_{\text{hit}} = \texttt{step->GetPreStepPoint()->GetGlobalTime()}.
$$
You then store t_hit inside the hit object along with energy deposition and position. In the event action, or later in your offline analysis, you loop over the hit collection, group hits by detector ID, and compute time differences between detectors.
More complex systems, such as PET scanners or large detector arrays, extend this logic. You may require that both hits lie not only within a time window, but also within an energy window, for instance close to a photopeak. This creates an energy and time coincidence condition that can be written as
$$
\begin{aligned}
|t_A - t_B| &< \Delta t_{\text{coin}}, \\
E_{A,\min} < E_A &< E_{A,\max}, \\
E_{B,\min} < E_B &< E_{B,\max}.
\end{aligned}
$$
The times $t_A$ and $t_B$ are still taken from your simulated hits; the energy bounds represent detector thresholds and photopeak selection. Geant4 itself does not enforce these cuts; you implement them in user code based on your physics goals.
Coincidence timing is also used for higher multiplicity events. For example, you can define triple coincidences where three detectors must all fire within the same time window. A simple way to handle this programmatically is to take one reference time, for example the earliest hit time in the event, and then check that all other required detector hits occur within $\Delta t_{\text{coin}}$ of that reference. The choice of reference does not change the physical logic, only the practical implementation.
In simulations that include realistic detector effects, you often shift the raw Geant4 times by additional delays that represent light transport, electronics, or cable delays. For instance, if you have a signal propagation velocity $v_{\text{signal}}$ along a detector of length $L$, and the interaction occurs at a distance $x$ from the readout, the signal arrival time at the electronics can be approximated as
$$
t_{\text{arrival}} = t_{\text{hit}} + \frac{x}{v_{\text{signal}}}.
$$
You can compute $x$ from the local hit position in the detector, then replace $t_{\text{hit}}$ by $t_{\text{arrival}}$ when applying coincidence logic. This lets you study how geometry and signal propagation influence the coincidence timing performance of your system.
Coincidence timing is often summarized by distributions of time differences. For two detectors you can fill a histogram of $\Delta t = t_A - t_B$ for all events that pass basic energy cuts. The width of this distribution, usually characterized by its full width at half maximum, is used to quantify the timing performance of the simulated system. How to smear or broaden this distribution to match realistic detector time resolution is described in the next section.
Time resolution
Real detectors do not measure time perfectly. Even if two identical particles hit identical detectors at exactly the same time, the recorded times will fluctuate from event to event. This spread in measured times is called the time resolution of the detector. Geant4 by default provides ideal times with no intrinsic jitter, so to model realistic timing you must introduce time resolution in your user code or during analysis.
Time resolution is commonly characterized by a Gaussian distribution around the true time. If the true interaction time is $t_{\text{true}}$, the measured time $t_{\text{meas}}$ is modeled as
$$
t_{\text{meas}} = t_{\text{true}} + \delta t,
$$
where $\delta t$ is a random number drawn from a normal distribution with mean zero and standard deviation $\sigma_t$. The parameter $\sigma_t$ describes the time resolution. In terms of full width at half maximum,
$$
\text{FWHM} \approx 2.355 \,\sigma_t.
$$
Gaussian time smearing:
To apply a time resolution $\sigma_t$ to a simulated hit time $t_{\text{true}}$, compute
$$
t_{\text{meas}} = t_{\text{true}} + \mathcal{N}(0,\sigma_t),
$$
where $\mathcal{N}(0,\sigma_t)$ is a Gaussian random variable with mean 0 and standard deviation $\sigma_t$.
In a Geant4 application, $t_{\text{true}}$ is usually the global time from the step that created the hit. You can implement the smearing directly in your hit class or when you finalize the event data. For example, in your sensitive detector you might obtain the true time with
$$
t_{\text{true}} = \texttt{step->GetPreStepPoint()->GetGlobalTime()},
$$
then draw a random Gaussian offset using the Geant4 random functions, and store $t_{\text{meas}}$ in the hit instead of the ideal time. This way any later analysis automatically uses the smeared times.
It is often useful to distinguish between single detector time resolution and coincidence time resolution. If two detectors have independent Gaussian resolutions $\sigma_{t,1}$ and $\sigma_{t,2}$, the uncertainty in the measured time difference $\Delta t_{\text{meas}} = t_{\text{meas},1} - t_{\text{meas},2}$ is larger. Assuming independent Gaussian fluctuations, the combined coincidence resolution $\sigma_{\text{coin}}$ is
$$
\sigma_{\text{coin}} = \sqrt{\sigma_{t,1}^2 + \sigma_{t,2}^2}.
$$
Coincidence time resolution (two detectors):
For two detectors with independent Gaussian resolutions $\sigma_{t,1}$ and $\sigma_{t,2}$, the standard deviation of the time difference is
$$
\sigma_{\text{coin}} = \sqrt{\sigma_{t,1}^2 + \sigma_{t,2}^2}.
$$
This relation explains why even good single detector timing can lead to a broader coincidence time distribution. In your simulation you can check that your applied smearing produces a coincidence time spectrum with the expected width.
Time resolution can also depend on other quantities, such as the deposited energy or the position inside a detector. A common model in scintillation detectors relates the time resolution to the square root of the number of detected photons. Since the number of photons roughly scales with energy, a simplified energy dependent time resolution can be written as
$$
\sigma_t(E) = \frac{k}{\sqrt{E}},
$$
where $E$ is the deposited energy in appropriate units and $k$ is a constant that you choose to match experimental performance. In code you would first compute or obtain $E$, then compute $\sigma_t(E)$ for that hit, then apply a Gaussian smearing with that event specific $\sigma_t(E)$.
When you introduce time resolution into a Geant4 simulation you should consider where in the workflow it belongs. If you smear times directly in the sensitive detector, the stored hit times already include detector effects, which is convenient for later analysis but makes it harder to recover the ideal times. If you prefer to keep ideal times, you can instead store both ideal and smeared times in your hit object, or apply smearing only at the analysis stage outside Geant4. Both approaches are valid; the choice depends on how you want to use the simulation results.
Finally, time resolution and coincidence timing are strongly linked. The choice of coincidence window $\Delta t_{\text{coin}}$ should be related to the coincidence time resolution $\sigma_{\text{coin}}$. If the window is too narrow compared to the resolution, you will lose true coincidences. If it is too wide, you will increase accidental coincidences from unrelated events. In your simulation studies you can vary $\sigma_t$ and $\Delta t_{\text{coin}}$ to understand this trade off and to design timing conditions that are realistic for your detector system.
Views: 10