30.5. Missing Energy Deposition

Typical Symptoms

Missing energy deposition problems usually appear in a few characteristic ways. You may see events where no hits are recorded in a detector volume that you expect to be active. Histograms of deposited energy can be completely empty or show far fewer entries than the number of simulated events. You might also observe that particles appear to fly through your detector in the visualization, but your analysis output files contain no energy information.

Sometimes the issue is more subtle. For example, you might see only very small energy deposits when you expect full absorption, or only some detector elements respond while others remain always at zero. Recognizing these patterns helps you narrow down where to look in your code and configuration.

Verifying That Energy Is Actually Deposited

Before suspecting your readout, you should confirm that energy is truly being deposited in the material. The most direct way is to inspect the information contained in steps and tracks.

Use the stepping verbose level through macro commands, for example /tracking/verbose 1 or /process/verbose 1, to print details of each step. For relevant volumes, you should see nonzero values of dE or Total energy deposit. If all steps in your detector material show dE=0, then the particle is not losing energy there. This can happen if the physics list does not include the right processes, the material is not what you think it is, or the particle simply never enters the volume.

You can also temporarily add debug prints to your SteppingAction. Access G4Step, and query step->GetTotalEnergyDeposit(). Print the deposited energy along with the volume name, using something like step->GetPreStepPoint()->GetTouchableHandle()->GetVolume()->GetName(), to see where and whether energy loss occurs. This is slower but very useful when debugging a small number of events.

If the verbose output shows that particles do deposit energy in your detector volume, then the problem lies in how that information is collected and stored as hits or analysis data. If there is no deposition at all, focus first on geometry, materials, and physics configuration.

Geometry and Volume Assignment Issues

A very common reason for missing energy deposition is that the geometry is not what you think it is. Particles might never enter the intended detector volume, even though the visualization suggests otherwise.

First, check that the world volume is large enough and completely surrounds your detector. If a detector extends outside the world, tracks can be terminated before entering it, and no energy will be deposited there. You can print the world volume dimensions and verify them against the detector size.

Second, verify that the detector volume really exists and is placed as you expect. Use commands such as /geometry/test/run or visualization commands like /vis/drawVolume to inspect your geometry. Look for shared boundaries and possible overlaps that might make Geant4 misinterpret where a step is located.

A frequent subtle error is that energy is being deposited in a different volume than the one you have marked as sensitive. For example, you might have created a separate logical volume for a dead layer or wrapping and attached the sensitive detector to the wrong one. When you examine steps, pay attention to the exact logical volume names reported and compare them with the names you assign to sensitive detectors.

If you use parameterized or replica volumes, confirm that the parameterization or replication is applied to the logical volume that is actually traversed by the particles. A mismatch between the hierarchy used in placement and the hierarchy used in sensitive detector assignment can lead to energy being deposited in physical volumes that are not connected to your sensitive detector code.

Finally, remember that the simulation uses logical volumes and physical placements distinctly. Sensitive detectors attach to logical volumes. If you accidentally attach a sensitive detector to a logical volume that is never instantiated in the geometry, no hits will ever be created even if the volume name looks reasonable in your code.

Physics and Production Cuts

If particles cross your detector but do not lose energy, the issue is usually in the physics list or production cuts. For most electromagnetic processes, Geant4 needs a suitable physics configuration to simulate ionization and other interactions that generate energy deposition.

First, confirm that you are using a reference physics list appropriate for your application, such as a list that includes electromagnetic physics. If you accidentally use a custom physics list that omits ionization or multiple scattering, charged particles can propagate with almost no energy loss. Check that photons have processes like the photoelectric effect, Compton scattering, and pair production enabled when they are relevant for your energy range.

Production cuts control the threshold for creating secondary particles. If the cuts are extremely large compared to your detector dimensions, secondaries may not be produced at all inside your detector. While this mainly affects secondary particle creation, it can also influence how energy is apportioned between tracks. Ensure that your production cuts are reasonable relative to the size of your sensitive region, typically much smaller than its thickness.

It is also possible to misconfigure your physics so that particles are killed before reaching the detector. For example, applying a range or time limit in the wrong region can stop tracks upstream. To debug this, look at the track status and track length in the verbose output, and identify where the tracks are terminated. If most primaries die before they reach your detector volume, no energy can be deposited there.

If you are working with specialized particles, for example optical photons, remember that they often do not deposit energy in the same way as charged particles. For pure optical simulations, almost all energy deposition comes from the underlying ionizing particle steps, not from optical photons themselves.

Sensitive Detector and Hits Problems

Once you know that energy is physically deposited in your detector volume, the next place to look is your sensitive detector implementation. Missing hits or empty hit collections are a frequent source of confusion.

First, confirm that you have correctly derived your detector class from G4VSensitiveDetector and that it is registered with the G4SDManager. This is normally done in your DetectorConstruction or a related helper class. If you forget to register the sensitive detector, Geant4 will never call your ProcessHits() method, even though energy is deposited in the volume.

Next, verify that the logical volume you want to read out has its sensitive detector set with something like logicalVolume->SetSensitiveDetector(mySD). If you accidentally attach the sensitive detector to a different logical volume or forget this step entirely, your detector logic will never see any steps.

Inside ProcessHits(), make sure you actually create and store hits when there is a relevant energy deposit. Many beginners write a ProcessHits() that only creates a hit if edep > 0, but then they accidentally use GetNonIonizingEnergyDeposit() or otherwise query the wrong quantity. Use step->GetTotalEnergyDeposit() to get the deposited energy on that step and test it against a sensible threshold. Also ensure that you add the new hit to the appropriate hits collection that you created in Initialize().

If you are using multiple sensitive detectors or multiple hit collections, check that the collection IDs are obtained correctly in your EventAction or analysis code. A wrong collection index will lead you to read from an empty or unrelated collection, which looks like missing energy even though the hits exist elsewhere.

Finally, confirm that ProcessHits() is actually being called. You can add a temporary print statement at the beginning of the method and run a small number of events. If the print never appears, the sensitive detector is not connected correctly to the geometry or not registered at all.

Step Filtering and Thresholds

Sometimes the detector and physics are correct, but application code filters out most or all of the energy deposition. This can happen in both SteppingAction and sensitive detector code.

In SteppingAction, check whether you return early for certain volumes or particle types. For example, code that only accumulates energy for primaries with track->GetParentID() == 0 will ignore all energy from secondaries. In some detector designs a large fraction of the total deposited energy can come from secondary electrons or photons. If all secondaries are excluded by design, the total energy will appear smaller than anticipated.

Also review any energy thresholds you apply. If you discard steps with edep < threshold and the typical step energy loss is much smaller than this threshold, then almost all deposition is thrown away. It is usually better to collect all step energy and apply cuts later in analysis if needed.

For sensitive detectors, make sure your ProcessHits() does not silently return when certain conditions are not met. Any conditional logic based on track status, kinetic energy, or volume name needs to be reviewed. A common trap is to check the post–step volume instead of the pre–step volume, which can cause hits to be missed when a track leaves the volume on that step.

If you use region based cuts or custom step limiters, confirm that the step size is not forced so large that energy loss is not recorded where you expect. Very large steps can cause energy deposits to be assigned to only one of the volumes the step traverses, which might not be the one you consider as your detector. Monitoring the step length per volume will help you catch such issues.

Analysis and Output Mistakes

In many cases, the underlying simulation and hit creation work correctly, but the final analysis does not show energy because of errors in how data is read and stored. This is especially frequent when using the Geant4 analysis system or writing custom output files.

Check your RunAction and EventAction code to make sure that you open, write, and close analysis files properly. If you forget to call the final write and close functions at the end of the run, the output may be empty despite being filled in memory during the run.

When creating histograms and ntuples, verify that you call the correct Fill methods for the objects you want. Using the wrong histogram ID or ntuple column index can silently place values in a different object than the one you are plotting later. Compare the IDs returned by the analysis manager when you create histograms and ntuples with the ones you use while filling.

In EventAction, ensure that you are actually summing energy from the hit collections and resetting any per event accumulators correctly. For example, if you intend to sum energy across all hits in an event but accidentally overwrite the sum in each iteration, you may end up with only the last contribution. Similarly, if you forget to initialize your accumulation variable to zero at the start of each event, you can mix energy from multiple events or from previous runs.

Another subtle issue is unit conversion. If you store energies in one unit but interpret them in another, the histogram may appear empty or incorrectly scaled because all values fall outside the expected range. Always use explicit Geant4 units when filling histograms or ntuples, and check the range of your histograms against the typical values you expect from the simulation.

Finally, when you inspect the output with an external tool, such as ROOT, make sure you open the correct file and the correct tree or histogram. If you reuse file names between runs, you might accidentally look at an older output file that was empty, misinterpreting it as a current problem.

Using Verbose Output to Locate the Problem

Verbose output is one of the most effective tools for pinpointing where energy disappears in a Geant4 simulation. You can control the verbosity level of several components using macro commands, which is especially helpful when you do not want to recompile.

Start by enabling tracking verbose output with /tracking/verbose 1. This will show you basic information about each track and its steps, including the position, volume, and energy changes. You can increase verbosity further if needed, but even a low level is often enough to see whether tracks reach the detector volume and whether they deposit any energy there.

To inspect the physics processes that are active and when they fire, use /process/list to print the processes for a given particle. Then enable process verbose output with /process/verbose 1. During the run, you will see which process is responsible for each step. This helps you determine if processes like ionization or Compton scattering are active in the detector material.

For geometry checks, use /geometry/test/run to have Geant4 search for overlaps and other issues that may influence tracking. Combine this with visualization commands such as /vis/open, /vis/drawVolume, and various view and style changes to see where particles are relative to your detector.

By gradually increasing the detail of verbose output only in the problematic region or for a subset of events, you can trace the path from the primary particle to the final hit or lack of hit. At each stage, check where the information stops making sense. If energy is deposited in steps but not seen in the sensitive detector, the problem lies in the detector assignment or ProcessHits(). If the sensitive detector records energy but the event analysis does not, the issue is in your hit collection handling or analysis code.

Using verbose output in a focused way lets you isolate the exact piece of the simulation chain where energy deposition is lost and correct the corresponding code or configuration.

Views: 11