KAHIBARO
13.5. Parent and Secondary Particles
Table of Contents
Primary particles
In a Geant4 simulation, every track belongs to a particle, but not all particles play the same role. The particles you explicitly create in your primary generator, for example with G4ParticleGun or G4GeneralParticleSource, are called primary particles. Each primary particle starts its own track when the event begins.
Primary particles are the starting points of the physics in an event. They define what enters your simulated geometry, such as an incident gamma ray, an electron beam, or a proton pencil beam. Geant4 gives each primary particle a unique track, represented by a G4Track object, and that track has a special status: it is not produced by any previous interaction in the simulation.
For a primary particle track, two identifying properties are important. First, its track ID is usually 1 for the very first primary track in an event, and increases if you have multiple primaries in the same event. Second, its parent ID is 0, which signals that this track has no parent. This parent ID is what Geant4 uses to distinguish primaries from particles created later in the event.
The behavior of a primary particle in your geometry, such as how it loses energy, scatters, or creates new particles, is governed by your chosen physics list. As a primary moves and interacts, Geant4 may create new tracks for additional particles. Those new tracks are not primaries, but secondaries.
Secondary particles
Secondary particles are created during the transport of primary particles, or during the transport of other secondaries. Whenever a physical process in Geant4 produces additional particles, for example a gamma producing an electron and a positron by pair production, Geant4 creates new G4Track objects to represent them. These tracks correspond to secondary particles.
Secondaries are important because they often carry away part of the energy and momentum from the primary. In many detector simulations, the signal you care about, such as deposited energy in a scintillator or charge collected in a semiconductor, comes mainly from the behavior of secondary electrons and positrons rather than the original primary.
Each secondary track stores information about the particle type, momentum, energy, creation position, and creation time. In addition, Geant4 records which track produced this secondary. This information is stored as the parent ID and allows you to reconstruct particle histories and build a picture of how the event evolved.
Secondaries can themselves generate further secondaries. For example, a high energy electron may produce bremsstrahlung photons, which then create further electron positron pairs. This leads to a tree structure of particle production inside a single event. Geant4 keeps this structure implicit through the combination of track IDs and parent IDs.
In user code, you typically access secondary information in actions such as SteppingAction, TrackingAction, or StackingAction. For instance, in a SteppingAction, you can inspect the secondaries created in the current step through the G4Step object. This makes it possible to count how many secondaries of a given type were created, or to apply special treatment to certain secondary particles based on their origin.
Parent IDs
Every track in Geant4 has a track ID and a parent ID. Both are available from G4Track, for example through methods like GetTrackID() and GetParentID(). Together, these two integers define how tracks are related to each other within an event.
The track ID is a unique number assigned to each track in an event. Geant4 starts counting at 1 and increments the ID each time a new track is created. The parent ID stores the track ID of the particle that created the current track. For a primary particle, there is no creator, so its parent ID is defined as 0. For a secondary particle, its parent ID is the track ID of the particle whose interaction produced it.
Important rule:
A track with parentID = 0 is a primary particle. Any track with parentID > 0 is a secondary (or higher generation) particle, and its parent is the track with trackID = parentID.
This rule lets you identify primaries and secondaries programmatically. For example, you can write code in a TrackingAction to execute special logic only for primary particles by checking whether GetParentID() returns zero.
Using parent IDs, you can reconstruct whole particle families. Suppose you have a track with trackID = 10 and parentID = 3. You know that track 3 produced track 10. If track 3 has parentID = 1, then track 1 produced track 3, and so on. In this way you can follow the chain back to a primary particle.
A common pattern is to tag or filter tracks based on their parentage. For instance, you might be interested only in secondaries produced directly by the primary, which means you would select tracks with parentID = 1. Alternatively, if you want to treat all non primary particles the same way, you check for parentID > 0. In StackingAction, this can be used to classify tracks, for example by killing unwanted secondaries or storing only specific families of particles.
Parent IDs never cross event boundaries. Track IDs and parent IDs are reinitialized for every new event, so a track in one event cannot be the parent of a track in another event. This makes analysis simpler, since the hierarchy is always contained within a single event.
By understanding and using parent IDs, you can connect energy depositions and detector hits to the particles that caused them, and ultimately to the initial primaries you defined. This ability to trace causality in the simulation is essential for detailed detector studies and physics analyses.
Views: 8