Zero energy deposited when using GPS with Co-60 radioactive decay (G4RadioactiveDecayPhysics enabled)

Particles, Track, Event, Run and Biasing
1

Hello Geant4 community,

I am trying to simulate a Co-60 radioactive source using G4GeneralParticleSource (GPS) with true nuclear decay physics (i.e., letting Geant4 emit the gammas via G4RadioactiveDecayPhysics instead of manually shooting gammas).

However, I am consistently getting zero energy deposited for all events, even though my detector fully surrounds the source.

Simulation Setup

Geometry

  • Detector: Spherical LaBr3 shell
    • Inner radius: 5 mm
    • Outer radius: 5.5 cm
    • Centered at the origin
  • Source: Point source at origin
  • World/envelope: Air

The detector completely encloses the source.

Physics List

In main():

auto physicsList = new QBBC;
physicsList->RegisterPhysics(new G4RadioactiveDecayPhysics());
physicsList->SetVerboseLevel(1);
runManager->SetUserInitialization(physicsList);

I also call:

G4GenericIon::Definition();

Primary Generator (GPS, no macro file)

PrimaryGeneratorAction::PrimaryGeneratorAction()
{
  fGPS = new G4GeneralParticleSource();

  // Position: point source at origin
  fGPS->GetCurrentSource()->GetPosDist()->SetPosDisType("Point");
  fGPS->GetCurrentSource()->GetPosDist()->SetCentreCoords(
    G4ThreeVector(0, 0, 0)
  );

  // Angular: isotropic
  fGPS->GetCurrentSource()->GetAngDist()->SetAngDistType("iso");

  // Energy (set to zero to let radioactive decay generate gammas)
  fGPS->GetCurrentSource()->GetEneDist()->SetEnergyDisType("Mono");
  fGPS->GetCurrentSource()->GetEneDist()->SetMonoEnergy(0.0);
}

void PrimaryGeneratorAction::GeneratePrimaries(G4Event* event)
{
  G4GenericIon::Definition();

  // Co-60 nucleus
  auto ion = G4IonTable::GetIonTable()->GetIon(27, 60, 0. * keV);
  fGPS->SetParticleDefinition(ion);

  fGPS->GeneratePrimaryVertex(event);
}

Output

For all events:

Gamma 0 deposited 0 keV
Gamma 1 deposited 0 keV
Gamma 2 deposited 0 keV
...

Physics output confirms:

Process: RadioactiveDecay

is active for GenericIon.

What I Expect

I expect Co-60 to decay and emit 1.17 MeV and 1.33 MeV gammas, which should deposit energy in the surrounding LaBr3 detector.

Question

What am I missing in my GPS / radioactive decay setup that prevents gammas from being generated or tracked?
Is there a required setting (e.g. particle lifetime, ion time, region cuts, or GPS configuration) that I have overlooked?

*Geant4 Version:*11.4.0
Operating System: Windows
Compiler/Version: MSVC (Visual Studio 2022) – MSBuild 18.0.5
*CMake Version:*4.1.1-msvc1

1 Like
2

Dear @Anamika_Patel

Thank you for your detailed report. It is possible that the time threshold for simulating decays might be set too low. Could you please try using a value similar to the one in the radioactive decay example? [1]

Additionally, to better understand the simulation, it may be helpful to print out the track information using /tracking/verbose 2 or to visualize the tracks directly.

Thank you for your time and efforts.

Best regards,
Alvaro
[1] geant4/examples/extended/radioactivedecay/rdecay01/Co60.mac at b4a16de652ec244f7a0ecc0a5cacfee21930bf75 · Geant4/geant4 · GitHub

3

Dear Sir,

Thank you very much for your suggestion.

I realized that the issue was indeed related to the decay time threshold. Since Co-60 has a long half-life, the nucleus was not decaying within the default simulation time window, which resulted in zero energy deposition.

After setting:

/process/had/rdm/thresholdForVeryLongDecayTime 1.0e+20 s

and enabling tracking with /tracking/verbose 2 , I was able to observe the Co-60 ion undergoing radioactive decay and the emission of the expected gamma rays (1.173 MeV and 1.332 MeV). The detector now records non-zero energy deposition correctly.

Thank you again for your guidance and support.

Best regards,
Anamika Patel

4

It is an interesting conversation/observation.

Does it mean that we can control the emissions from daughters of a decay chain by changing this parameter? and the relative emissions in a decay chain will vary with this parameter?

With Regards,

Deepak Akar

5

It is a global time gate. You could “gate” down to a certain daughter roughly with

/process/had/rdm/nucleusLimits A1 A2 Z1 Z2

But finer control would be to filter by the parent (such as its local time) using PreUserTrackingAction.

6

Thanks for clarification.

My question was specifically to the use of thresholdForVeryLongDecayTime. Will it affect the relative yields from the daughters “during simulations”?

7

It would only affect yields from daughters which are themselves radioactive. Since Co-60 beta decays to stable Ni-60, there’s no daughter chain to be affected (as compared to U-238, for example). The excited states of the daughter aren’t treated by RadioactiveDecay itself, but rather by Deexcitation.

1 Like
8

yes, my intention was for decay chain involving the radioactive daughters.

Thanks

9

Okay, note that Geant4 does not solve the Bateman equations for secular equilibrium. When you start an event with the head of an alpha chain (U-238, Cf-252, whatever), Geant4 will decay the primary and assign it’s daughters a timestamp randomly thrown from the half-life. Then it’ll decay the daughter nucleus, and assign its daughters a timestamp from that half-life added to the parent timestamp, and so on. So you’ll get particles in your event with timestamps of millions or billions of years.

That’s what they introduced the half-life time threshold, because in terms of a detector readout, a daughter that decays in a week, a month, or a billion years is “effectively” stable.

There are event generators out there (like RadSrc or SOURCES4C), which will do secular equilibrium and give you a composite spectrum for the whole decay chain.

1 Like