Many of the files in RadiativeDecay3.0 contain incomplete entries, which result in a lot of strange
decays and hangs or very long times to complete a decay.  Bob Weller & I traced this to a number of
types of defects:

1) Entries in which there is a line for a total rate for a branch, but no detail lines, which results in
nothing appearing in the decay table.  This can be especially troublesome if the only other branch
provided has a very tiny total probability (e.g. 1e-9), since the total-probability correction code in the
file parser doesn't notice this inconsistency

2) entries in which a Q value is zero, especially beta decay entries, which (if the bad Q value is the only
detail line for the branch), also results in no entry in the decay table, and can cause problems similar to
1)

3) Entries in which an IT is marked as returning to the same state it started, instead of the ground state,
which if it is the only channel in the file causes an infinite loop

There are a few other cases, but these are the most important ones.  At first, I spent some effort
thinking about fixing the parser to check for all these special cases, but then decided that it is silly to
make a parser have to keep rechecking files every time for being badly formed.  Why not fix the files
instead? It turned out that this was a fairly easy thing to do.  With a bit of python scripting, I made a
script which goes through all the files and looks for these types of problems.  It then rewrites every file
in a regularized form, so there are no anomalies for the parser to worry about.  The total process takes
about a minute on my laptop, so it is pretty easy.

I can send the script for you to examine and test.  As it stands, it looks for two things to be present:  A
set of input files in the directory pointed to by the environment variable G4RADIOACTIVEDATA and a
directory in the current directory, called fixed_decays, in which it writes the repaired files.  After
running the script, the repaired files are in the fixed_decays directory and can but put where they are to
be used.  This script downloads a large table of atomic masses from NIST, and rechecks all the Q values
in the input files.  In cases in which the Q value is specified as 0 and shouldn't be, it puts in the
theoretical value from the NIST masses for the specific reaction.  It also cross checks all Q values in the
file, and annotates with a "W" line cases in which the original Q value (which is retained as the actual
output) differs by more the 10 keV from what was expected.  To run this script, just create the
fixed_decays directory, set up the environment variable, and do

python repair_decay_files.py

and it will print a long verbose log to the terminal window as it does its work.  It should work with
python 2.3 and greater.

The resulting 'preened' files seem to give much more reasonable overall results in situations in which
decays are being tracked.  There are still some funny problems in G4RadioactiveDecay, though.  For
nuclides which have a few hundred decay branches (to many excited states of the daughter nucleus), it
can take as much as a second to complete a single decay.  There is something wrong here that I have
not tracked down yet.  Also, if I run a program which successively decays a few times every species for
which a file is available, the whole process gets slower and slower, either as the number of ions in the
particle table increases, or something.  I have not tracked this down, either.

We are expecting to have significant need of good results from G4RadioactiveDecay, and are willing to
work with the Geant4 team at some level to help further debug and optimize it.  In the interim, I think if
you start distributing, in lieu of the standard RadiativeDecay3.0  files, ones which have been cleaned up
by the attached script, most users will see more rational decays schemes, and you may have to listen to
less complaining.  Incidentally, the repair to z81.a188 must be made for this script to work on that file.
Any files which cannot be parsed by this script because of a serious defect of that type will be inserted
in the output stream as, e.g. z81.a188.FIXME and will not have been corrected.

Let us know how to proceed with this.