I am using Geant4.10.6 for simulating excited ions which de-excite emitting gamma rays.
The ions are generated inside a target (G4_U material) with a kinetic energy and an excitation energy. The generation is done with an user defined “PrimaryGeneratorAction” class, in which I use:
G4ParticleDefinition* ion = G4IonTable::GetIonTable()->GetIon(Z, A, E_exc*MeV);
G4ThreeVector thisPosition = G4ThreeVector(0.,0.,0.);
G4ThreeVector thisDirection = G4ThreeVector(x, y,z);
fParticleGun->SetParticleDefinition(ion);
fParticleGun->SetParticlePosition(thisPosition);
fParticleGun->SetParticleMomentumDirection(thisDirection);
fParticleGun->SetParticleEnergy(KE);
fParticleGun->GeneratePrimaryVertex(anEvent);
The problem is that the ions first de-excite emitting gamma rays, then (when they are at ground state) they loose their kinetic energy in the target material.
Dear all,
Maybe the question wasn’t so clear, therefore I show you the output of the tracking verbose.
I am using excited 100Zr (1294 keV) created at a defined position (x,y,z) with a kinetic energy of 103 MeV, inside a target (G4_U and G4_Be materials which easily should stop the ions).
As you see in the tracking verbose output, the ion doesn’t loose kinetic energy but it de-excite emitting a gamma-ray of 1.13 MeV.
Then, there is another step, because the 100Zr has 212 keV excited energy, but again it de-excite emitting gamma ray and doesn’t loose energy in the target.
I’m pretty sure that what you describe is how the Geant4 processes are configured: nuclear de-excitation happens first, then the ground-state nucleus is transported and does its thing, losing kinetic energy until it stops. The timescale for de-excitation is so much shorter than for transport, that even in real life the excited state isn’t going to last long enough for its mass difference to have an effect on the energy loss.
The easy-to-read tracking verbosity (/tracking/verbose 1) doesn’t show the timestamps, but if you crank it way up (/tracking/verbose 3) you can see the time assigned at each step.
Hi all,
If the explanation given is true, i.e. that geant4 first de-excites the ion and then does the transport this has to be considered a bug and fixed! Using geant4.9.6.p04 I have done a lot of simulation of nuclear physics experiments where it is the fact the the ion moves before and between de-excitation that gives the wanted effect (for the interested recoil distance dopper shift method at DuckDuckGo). My question is how can we fix this ( I have in the past debugged similar problems with earlier versions of geant4)
On PhotonEvaporation data set, you will see that 100Zr [1294.85 keV] has a null life time. Once created, it will decay instantaneously.
Life time of 100Zr [2259.71 keV] is 2.5 ns. It will travel before to decay.
Here, a macro for TestEm1 which illustrates these two situations.
I am trying using the TestEm1, but I have some problems in building it.
Anyway, together with 100Zr in the simulation that I run, there was also 134Te, in non-zero lifetime excited states:
Te134[1691.340] 164.1 ns
Te134[1576.130] 1.36 ns
but the result is the same as for 100Zr, as you can see from the tracking verbose:
Hi, I found the problem comparing my code with the example TestEm1.
In the PhysicsList.cc I need to specify G4NuclideTable::GetInstance()->SetThresholdOfHalfLife(0.01*picosecond)
with sub-ps half-life which is more reasonable than the default 1 microsecond.
sorry to get back to this topic but I don’t quite understand what different data files are used for… I have discovered that if I want to change the lifetime of a nuclear state I have do change/add this state to the ENSDFSTATE.dat file. It does not matter what I give as lifetime in neither G4RADIOACTIVEDATA/zZZ.aAAA or G4LEVELGAMMADATA/zZZ.aAAA for a state.
So far so good, but I then ask myself if these three files have to be consistent? For a nuclear level with lifetime>0 should I have an entry in the ENSDFSTATE.dat file, one in the G4RADIOACTIVEDATA/.zZZ.aAAA as an “IT” transition and the correct lifetime in the G4LEVELGAMMADATA/zZZ.aAAA file as well? Or is it “enough” to modify in the ENSDFSTATE.dat file…? Which file is used for what under the hood? I lost track of this moving from 9.6->9.10
