30.4. Missing Particles

Table of Contents

Understanding “Missing” Particles

When you run a Geant4 simulation, you may sometimes notice that particles you expect to see simply do not appear. They may not show up in your trajectories, they may never reach a given detector, or they may not be present in your output at all. In most cases Geant4 is doing exactly what you asked, but your setup, physics, or analysis logic is unintentionally discarding or stopping those particles.

This section focuses on typical reasons why particles seem to be missing, and how to systematically track down the cause.

A “missing particle” is almost never a Geant4 bug. It is usually caused by:

Incorrect particle definition or source configuration.
Geometry or material setup that blocks or absorbs the particle.
Physics list or production cuts that prevent the particle from being created or transported.
User actions or stacking logic that kill the particle or ignore it in the analysis.

Checking the Primary Particle Source

The first step is to verify that the particles you expect are actually being generated as primaries. Problems in the primary generator are a very common cause of missing particles.

If you use G4ParticleGun or G4GeneralParticleSource, check that the particle type, energy, position, and direction match what you think you are simulating. It is easy, for example, to set a very low energy, point the gun away from the detector, or place it outside the world volume, so the particle never reaches the region of interest.

Use verbose output and macro commands to confirm source settings. The /run/beamOn command will generate events, but if your source logic depends on uninitialized variables or is never called, no primaries will be created. You can temporarily add G4cout statements in GeneratePrimaries to print the particle name, energy, initial position, and direction for each event. If those printouts are missing or have unexpected values, fix the primary generator before looking elsewhere.

If you rely on macro commands such as /gps/particle, /gps/energy, or /gps/pos/type, double check the macro file that you actually run. It is common to edit one macro and then execute another one, which still configures a different particle or energy. Always confirm the macro path and that the macro is executed before /run/beamOn.

Geometry and Acceptance Issues

Sometimes the particles are created, but they never reach the part of the geometry you are looking at. They may start outside the world, be completely shielded by other volumes, or miss your detector because of their direction or spread.

Use visualization to inspect your geometry and the primary positions. With the commands to draw volumes and tracks, verify that the source is inside the world volume and points toward your geometry. Even a small rotation error can steer all particles away from the detector. If you see that no trajectories cross your detector volume, the particle is not missing, it simply never has a chance to get there.

Another frequent geometry issue is that the detector is accidentally placed outside the world volume, or it is placed in a region that is never reached because there is an unintended blocking volume. Overlaps or wrong placements can make logical volumes inaccessible. Use the geometry overlap checking tools to confirm that your detector is actually present and reachable.

If you use repeated or parameterized geometry for arrays, check that the copy numbers and placements are correct. A mismatch between where you think the detector is and where it actually is can make you look for particles in the wrong place.

Physics List and Production Cuts

Even if particles are geometrically able to reach a detector, they may be killed or never created by the physics configuration. If you do not include the relevant particle type or interaction process in your physics list, Geant4 cannot transport or produce that particle.

For example, if you expect optical photons but you have not activated optical physics, no scintillation or Cherenkov photons will be produced. If you expect thermal neutrons but your physics list does not include appropriate low energy neutron models, they may be absorbed or not transported as you expect.

Production cuts can also make secondaries appear to be missing. Geant4 uses production thresholds (in length or equivalent energy) to decide whether to produce certain secondary particles, such as delta electrons or low energy photons. If the cuts are set too high, low energy secondaries will not be generated at all. This is not merely a numerical approximation, it completely removes those secondaries from the simulation.

If a secondary particle’s range is below the production cut, that secondary is not created. To see low energy secondaries, you must reduce your production cuts.

If you expect many secondary electrons, photons, or positrons and do not see them, inspect your physics list choice and production cuts. For reference physics lists, there are helper macros that print or adjust cuts, and you can decrease them for sensitive regions only if needed.

User Actions and Stacking Logic

Even when particles are created and transported, user code can kill them prematurely or ignore them in the analysis. This often happens in G4UserStackingAction, G4UserTrackingAction, or G4UserSteppingAction.

In a stacking action, you can classify tracks into different stacks and even kill them by returning a status that discards them. If your logic is too aggressive for performance reasons, or if a condition is wrong, you may be killing particles you actually care about, such as all secondaries or all particles below a certain energy threshold.

In a tracking or stepping action, you might call methods that change track status. If you mistakenly set the track status to fStopAndKill under conditions that occur for many particles, you will again remove them from further transport. Particles then stop silently, and you see fewer tracks than expected.

If you are missing particular types of secondaries, temporarily disable or simplify your stacking and tracking actions. Let Geant4 transport everything and use verbose tracking to see what is happening. Once you confirm that the particles appear without custom actions, you can reintroduce your logic more carefully.

Sensitive Detectors and Hit Recording

Sometimes particles are not actually missing, but you have no record of their passage because your sensitive detector setup or hit logic does not record them. If your analysis only looks at hits, you may conclude that the particles never existed.

Verify that the logical volume you expect to be sensitive is actually assigned a sensitive detector object. If you assign the sensitive detector to the wrong logical volume, or forget to register it with the detector manager, no hits will be produced in your detector of interest.

Inside ProcessHits, you decide what constitutes a hit. If your conditions require nonzero energy deposit or a minimum energy, many valid crossings may be ignored. A very common pattern is to only create a hit if the deposited energy is positive. Neutral particles or minimum ionizing particles that deposit almost no energy in a thin detector may pass without creating any hits. In that case they are not missing, they are simply undetected by your current logic.

Use printouts inside ProcessHits to see which tracks enter the sensitive volume and which are ignored. If the function is never called, the volume may not be sensitive or may never be reached by any step.

Analysis Logic and Output Filters

Even when hits or tracks are correctly created, they can disappear from your final output if your analysis filters are too strict. For example, you may only fill histograms or ntuples for particles that meet certain criteria, such as:

Only primaries, or only a specific PDG code.
Only energy deposition above a threshold.
Only events with a particular detector ID.

If your selection cuts do not match the actual simulation, then you will not see certain particles in your ROOT files or CSV files, even though they are present in the simulation. This can give the impression of missing particles.

Check the conditions in your run, event, stepping, and analysis actions. To diagnose, temporarily loosen or remove all cuts and record every step or every hit for a small number of events. Inspect the resulting output in detail. If the particles appear in this exhaustive output, then the problem lies in your selection logic, not in the simulation itself.

Using Verbose Output to Trace Particles

When you suspect that a certain particle should appear but does not, verbose tracking is one of the most powerful tools. You can increase the tracking verbosity for all tracks or for specific events or regions using macro commands. Under high verbosity, Geant4 prints, for each step, the particle name, kinetic energy, process, and volume.

By looking at these traces, you can answer questions such as:

Is the primary actually created?
In which volume does it start, and what is its initial energy?
Does it undergo an interaction that kills it before it reaches the detector?
Are secondaries created, and what are their types and energies?
Where exactly do tracks stop, and why?

If you do not see any printed information for the particle type you expect, it points back to issues in the primary generator or physics list. If you see them being created and then killed early, examine the interaction processes and your user actions around those steps.

Verbose output is especially useful when diagnosing missing secondaries, such as annihilation photons, delta electrons, or optical photons. It can show you whether they are created, and if not, which process or cut is responsible.

A Step by Step Strategy to Find Missing Particles

When you encounter missing particles, follow a structured approach in a minimal test:

First, confirm primary generation by printing particle type, energy, position, and direction in GeneratePrimaries.
Second, visualize the geometry and trajectories for a few events to verify that primaries are in the correct place and direction.
Third, check the physics list and production cuts, ensuring that the relevant particle types and processes are active and that cuts are not too high.
Fourth, temporarily disable custom stacking, tracking, and stepping actions to see if particles appear without your user logic.
Fifth, confirm that sensitive detectors are correctly assigned and that ProcessHits is called as expected.
Finally, simplify your analysis filters and output everything for a small test run to verify that particles are present.

By following this chain from source, through geometry and physics, to user logic and analysis, you can usually identify the exact reason why particles appear to be missing and correct your simulation accordingly.