| Summary: | incomplete G4DecayTable for 194Tl | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | mmarino |
| Component: | processes/hadronic/models | Assignee: | flei |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | other | ||
| Hardware: | All | ||
| OS: | All | ||
Beta decay is defined in the data file of z81.a194 for RadioactiveDecay 3.0. However, beta decay is not available for 194 Tl. Radioatcive-decay package seems to have some problem. Yes, I find the same thing. In the data file for z81.a194:
# 194TL (33.0 m)
# Excitation Halflife Mode Daughter Ex Intensity Q
P 0.00000 1.980E+03
BetaPlus 0.00000 1.000E+00
Alpha 0.00000 1.000E-09
W No information available on excitation state of daughter.
W Decay directly to the ground state has been assumed.
Alpha 0.00000 1.000E+02 3490.00000
# 194TL (32.8 m)
# Excitation Halflife Mode Daughter Ex Intensity Q
P 0.00000 1.968E+03
which means it defines the beta-plus decay as existing, but does not specify any
information describing the decay. I think this is what was written earlier, but
I just wanted to clarify.
In addition, the infinite while(1) loop in the code above is unnecessary since
there should never be more than one loop over the decay channels. (There will
not be more than one loop if the sumBR can eventually equal 1.) Also, it is
important to check that the total Branching Ratio of the Decay Table is 1, and
if not then an error needs to be thrown indicating the problem. Perhaps this
can be done when the DecayTable is created within
G4RadioactiveDecay::LoadDecayTable(G4ParticleDefinition &theParentNucleus).
Best, Mike Marino
The problem is cause by the incomplete data in z81.a191 for 194Tl. This is a known problem for the current RadioactiveDecay database and there are a few other similar problematic isotopes which have been identified. The decay data files were extracted from the ENSDF database in 2002, and for those problematic isotopes the decay data were incomplete in ENSDF! The short-term fix to the problem is to remove the z81.a194 file from the database (this implies 194Tl will not be treated by G4RadioaactiveDecay). In the longer term, we need to update the RadioactiveDecay database using the latest ENSDF release. |
When running a program involving high energy muons incident on lead, I encounter an (almost) infinite loop in the G4DecayTable of 194Tl. This is within: G4VDecayChannel *G4DecayTable::SelectADecayChannel() { // check if contents exist if (channels->size()<1) return 0; while (1) { G4double sumBR = 0.0; G4double r= G4UniformRand(); // select decay channel G4VDecayChannelVector::iterator i; for (i = channels->begin(); i!= channels->end(); ++i) { sumBR += (*i)->GetBR(); if (r < sumBR) { return (*i); } } } return 0; } Using gdb, I get: (gdb) call DumpInfo() G4DecayTable: Tl194[0.0] 0: BR: 1e-09 [Phase Space] : alpha Au190[0.0] (gdb) call channels->size() $11 = 1 meaning there is only one decay channel registered (with such a small BR that it makes it practically impossible to select it without running for a long time). I'm pretty sure there needs to be an electron capture to 194Hg and maybe some other processes. I can't track this down any further (meaning I don't know if this is within a data file or hard-coded in). Please email me if there are any questions...