Large count at the first bin of the spectrum

Particles, Track, Event, Run and Biasing
1

Hi,
I was simulating a germanium crystal and as the source I placed a 5 MeV monoenergetic electron with isotropic distribution using GPS. I am attaching the GPS macro and the visualisation of geometry along with this. I have written the energy deposition data to root file and while analysing that, I could find there is an unusually large value at the first bin of the histogram. I tried the simulation with different types of detectors like silicon detectors, BC408 scintillators and all. But always there is a large peak in the first bin. I tried the simulations using different radioactive sources as well and I could find the same peak remains there.

c1
c1698×476 4.83 KB

picture._0000
picture._00001296×564 21.1 KB

When I integrated the total number of counts under the curve I obtained, I could see that it is 10^6 which is the same as the number of electrons I had projected isotropically. Now I did the simulation in a different way that all the projectile electrons are falling directly on the detector active area and no one is escaping. (The geometry and spectrum attached for reference.) .

images._0000
images._00001296×564 29.3 KB

c1_n2
c1_n2698×476 5.26 KB

Interestingly, the peak in the first bin vanishes.
So it is my guess that Geant 4 is putting all the particles not registered in the first bin of the histogram. But I couldn’t figure out how and why this happens. I have edited the example B4 for making the simulation and I am attaching my runmanager.cc along with this post. I couldn’t find any part responsible for this. I am also confused if it is some built in properties of the GPS package.
B4RunAction.cc (3.8 KB)
B4PrimaryGeneratorAction.cc (1.0 KB)
B4aSteppingAction.cc (1.5 KB)
B4aEventAction.cc (2.7 KB)

Thanks a lot in advance for your interest and time and the help is deeply appreciated.

1 Like
2

the first (and last) bin is for underflow (overflow) entries, i.e., when the entry does not have a suitable bin.

your histogram starts at 0 eV, hence I would place a tiny check for positive values before your recording code in the SteppingAction. Either, due to numerical stuff, the value of eDep could be negative numbers (although very close to zero), or if the limiting cause for the step is geometric boundary crossing, the energy deposition is actually zero.

void B4aSteppingAction::UserSteppingAction(const G4Step* step)
{
// Collect energy and track length step by step

  // get volume of the current step
  auto volume = step->GetPreStepPoint()->GetTouchableHandle()->GetVolume();
  
  // energy deposit
  auto edep = step->GetTotalEnergyDeposit();
  if(edep > 0) {  
    // step length
    G4double stepLength = 0.;
    if ( step->GetTrack()->GetDefinition()->GetPDGCharge() != 0. ) {
      stepLength = step->GetStepLength();
    }
      
    if ( volume == fDetConstruction->GetSiliconPV() ) {
      fEventAction->AddSil(edep,stepLength);
    }
  
    if ( volume == fDetConstruction->GetScintillatorPV() ) {
      fEventAction->AddSci(edep,stepLength);
    }
  }
}
1 Like
3

It seems that in EventAction, you fill systematically histos and ntuple, even if energy deposited is null. This happens very often with isotropic source (as in your first picture …)