I’ve found some problem in simulating the decay of the Th234 (in the chain of the U238) due to the floating level of the Pa234.
I have noticed that:
1- If Th234 decays on a Pa234[73.920X] it decays directly on the U234, that’s ok.
2- If Th234 decays on a more excited state of the Pa234, like the Pa234[166.3], this one decays on the Pa234[73.920U] and from this it decays on the Pa234.
The first decay way is right but the second one is not, because from the 79.92 level it should decay directly on U234. In fact, in the gamma spectrum, i see all the energies of the Pa234 decay!
How can i solve this issue?
Curiosity: what is the difference between the X and U levels?
Note: i use Geant4 10.3.1 - Radioactive decay 5.1.1 - Photonevaporation 4.3.2
use Geant4 10.5.1, with RadioactiveDecay 5.3 and PhotonEvaporation 5.3
Thank you, i’ve have installed the 10.5.1 and it works better!
The Pa234 is not present anymore but there is still an anomaly in the decay of the Pa234m.
The gamma energies with highest branching ration are the 1001 keV (0.85%) and the 766.4 keV (0.3%) but in the result of the simulation there is only the 1001 keV…
I’ve taken a look at the G4photonevaporation data and here is the level that generates the 766.4 keV:
7 - 809.907 1e-10 0.0 2
1 766.4089 0.329 4 0 0.0187 0.7155 0.1208 0.07509 0.01621 0.02888 0.02016 …
0 809.907 0.72 1 0 1.e20 0.8153 0.1164 0.01577 0.007808 0.02693 0.004124 …
- The branching ratio of the 766.4 keV is right, but it is not present in the simulation and i don’t understand why…
- The total internal conversion coefficient (alfa) of the 809.9 keV transition is 1e20 (why so high?) and it has also a high branching ratio…
- Some times the branching ratios are relative, and some times are absolute, why? is that right?
You are right. For state U234[809.907 keV] the internal conversion rate is 100%
This is clearly seen in example rdecay01 with macro below.
Forwarded to authors.
andrea.mac.txt (180 Bytes)
Thank you, i hope that this issue will be solved as soon as possible…
The absence of the 766.4 keV gamma is correlated to the internal conversion coefficient?
It shouldn’t be that way… but i don’t know why it is not generated…
is it possible to check new Geant4 10.6?
The problem seems to has been solved. I found out that there was a bug in the LevelReader.cc from the 10.4.p03, that has been fixed in 10.6.
Andrea wrote that the problem seems to be solved. I am using Geant4 10.7.2 with the data files PhotonEvaporation5.7. I still observe this problem: the 766.4 keV transition is missing when I simulate the decay 234Th → 234Pa → 234U. The other transitions are there, for example the 1001 keV transition. Perhaps I am doing something wrong?
I also have the same question as Andrea: why are the branching ratios given as a percentage of the decay of the parent nuclide for the 809.709 keV and 1044.536 keV levels in z92.a234, while for all other levels the branching ratios are given relative to the strongest transition, which is set to have a branching ratio value of 100?
Thank you for any advice or help you can give regarding this.
I confirm that the bug is still there…
The problem is the following:
In the PhotonEvaporation data files are reported the gamma relative intensities and the internal conversion coefficients of each transition, but for the 7-0 (809.907) transition of U234 (maybe also for other nuclides and transitions), the transition intensity is the total one and not the gamma.
As a consequence the computation done by the G4LevelReader class to compute the correct branching ratio is wrong.
I think there are two possible solutions: modify the G4LevelReader source code adding an exception for these types of transitions (if alpha = 1e20 then the intensity must be treated as total and not gamma), or modify the data file with the correct gamma intensity.
I think that for consistency in the data files and if there are no cons, the second option is better, but the correct value should be 0.72e-15 (instead of 0.72e-20) because alpha 1e20 is converted into 1e15.
Regarding the absolute/relative branching ratio, it is strange that this one is different from the others but it’s not a problem because the probabilities are renormalized.
I’ll report this bug on bugzilla.