Notes and Summaries from the Geant4 Radioactive Decay Mini-workshop

1. Notes and Summaries from the Geant4 Radioactive Decay Mini-workshop Dennis Wright 28 March 2016

2. Outline • Summaries from talks • last year’s progress • handling floating levels • database improvements • RDM tests (biased and un-biased) • problems with random number generators • using Geant4 for super-heavy elements • angular correlation of cascade gammas • discussion of floating levels • photon evaporation code improvements

3. Outline • Notes from Discussions • Use Cases and Requirements for Biasing • Tasks • Design Teams

4. Summaries from Talks • Progress since last year (talk by D.H. Wright) • RDM, PhotonEvaporation and ENSDFSTATE databases now consistent with one another • reproducibility problems (in both sequential and multithreading mode) have all been fixed • improved energy conservation for all RDM channels • refactoring of RDM non-biased code completed • code for angular correlation of cascade gammas nearly ready to be installed • photon evaporation code improved and updated • new channels added (decay by proton emission, neutron emission) • many lost levels found and bugs fixed

5. Summaries from Talks • Handling Unresolved (Floating) Levels (talk by T. Koi) • a non-negligible number of decay chains are based on levels whose energies are not known • levels denoted by guessed energy level plus X, Y, Z, etc. e.g. 108Tc[176.6+X] • currently treated in Geant4 as having energy 176.600004 in order to distinguish from known level nearby • 92 isomers identified which have this problem • agreed last year that these levels should be handled by model and propagated as a unique ion (distinct from nearby level) • proposed solution: set minimum difference between levels to be 1 meV in particle category and add character to particle name, e.g. 108Tc [176.6X]

6. Summaries from Talks • Handling Unresolved (floating) Levels (talk by T. Koi) • how to handle transitions from floating levels to non-floating levels (energy conservation problems) • 234Pa[73.92+X] particularly important example

7. Summaries from Talks • Database Improvements (talk by L. Desorgher) • levels in RadioactiveDecay4.3.1, PhotoEvaporation3.2.1 and ENSDFSTATE1.1 now consistent • some corrections for Geant4 10.2. p01 • Q values now taken directly from Qcalc • PhotonEvaporationdb now has easy-to-read format • corrected use of BRICC to compute internal conversion coefficients

8. Summaries from Talks • RDM tests (L. Desorgher) • single decay of different nuclei from example rdecay02 (gamma, x-rays, electrons from 214Bi, alphas from 238U, • generally good comparison to data • in biased mode, looked at activity in bunker walls from 45 MeV electrons (very good agreement) • example rdecay02: 137Cs, 99Mo, 226Ra => generally good agreement (see plots)

9. Summaries from Talks • Random number generators (A. Howard) • granularity and repetition are crucial for radioactive decay • serious issues with granularity and computation time observed • several engines tested: Ranecu, Ranlux, Ranshi, Ranlux64, Mersenne Twist, MixMax • race conditions appear in MixMax • Ranshi doesn’t produce randoms over full interval (0:1) • serious clumping observed in Ranlux • many other results plotted – see slides

10. Summaries from Talks • SuperHeavy Elements in Geant4 (L. Sarmiento) • proton emission experiment described – very sensitive • excellent agreement of experiment and Geant4 for 53Co • better atomic relaxation code is needed for x-ray fingerprinting of new heavy elements • high quality code is available – need to implement it rather than make work-around for current code • move away from current G4AtomicShells to G4AtomicShells_EADL

11. Summaries from Talks • Future Plans (D. H. Wright) • see section on to-do list and assigned tasks

12. Summaries from Talks • A Few Notes on X, Y, Z levels (M. Venhart) • floating levels (X, Y, Z, ..) occur for several reasons • gamma ray spectroscopy difficult in some cases • they decay by low energy transitions (hard to measure) • states fed only by other floating states • decay only by beta decay (hard to fit) • nobody tried to measure • mistakes were made • such states are general problem of nuclear physics • we must identify critical cases and evaluate data ourselves • 92 cases known so far

13. Summaries from Talks • Photon Evaporation Model Improvements (V. Ivantchenko) • messy design, many problems over the years • many problems fixed • 4-momentum balance • reduced memory churn and overhead • … • in order to fix many other problems, new code developed • default for 10.2 • old code still available • code used by • hadron inelastic • neutron capture • radioactive decay (with single gamma transition)

14. Notes from Discussions • Multithreading issues • locks currently slow down RDM when reading decay tables • checking that data is there causes delay • possible solution: use double checking as done in ion table (thread-local bool) or G4LevelManager in G4PhotonEvaporation • G4NuclideTable has hard-coded data which duplicates some parts of database, takes memory space • database storage could be optimized by using less granular groupings of files (such as one file with decay data from all nuclei with same A) • convert to binary to speed up reading • users would see no changes (granular ascii files still visible) • consider using SQLite which supports multithreading

15. Notes from Discussions • Dealing with floating levels • how do we handle transitions which are • floating to fixed • fixed to floating • check to see if any floating levels can be made fixed by evaluating existing data • when any change made, document in data file header • also any data coming from other than ENSDF (e.g. Nuclear Wallet Cards) should be documented in header • user should be able to configure data reader to set X, Y, and Z • nuclides with X, Y, Z etc. levels should be trackable objects, unique from nuclides with fixed level

16. Notes from Discussions • Dealing with floating levels • implementation: • extra argument for ions (character representing X, Y, Z, etc.) • Get, Find, Create methods in G4IonTable must all be changed • levels represented as 108Tc[176.6X], instead of 108Tc[176.600004] • does this pose a problem with too many digits? • extra column (with X, Y, Z etc.) to be added to database entries • still need to work out how to do transitions (truncate?) • 234Pa is an especially important case where floating levels are confused with fixed ones in the current implementation

17. Notes from Discussions • Dealing with floating levels • how do we handle transitions which are • floating to fixed • fixed to floating • check to see if any floating levels can be made fixed by evaluating existing data • when any change made, document in data file header • also any data coming from other than ENSDF (e.g. Nuclear Wallet Cards) should be documented in header

18. Notes from Discussions • Atomic de-excitation • current model is approximate and does not handle pick-up or loss of electrons into outer shells (e.g. for alpha, beta decay) • results in energy non-conservation • RDM currently uses G4UAtomicDeexcitation • should use G4VAtomicDeexcitation • detailed model of TiborKibedi is available as a possible replacement • currently local energy deposit is not done • implementing this may help a bit with energy non-conservation

19. Notes from Discussions • Beta-delayed neutrons • correct model would be to invoke precompound model after beta decay to highly excited level • however, the emission of beta and neutron appears to be nearly simultaneous • also the energy levels are spread out -> do we know level density at high excitations? • decide to implement directly within RDM (no precompound) • details of decay listed in ENSDF • new entries in table will be made • use 29Na as test case

20. Notes from Discussions • Redesign of biased radioactive decay • large project • currently in biased mode the RDM process accumulates rates within the process • no other Geant4 process does this -> should not be allowed • attempt to re-design based on generic Geant4 biasing • can generic biasing handle all existing RDM biasing options? • is it correct for both at-rest and in-flight decays • list of use cases and requirements compiled • see slides below • an example of how to proceed is in example GB01 • /examples/extended/biasing/GB01

21. Notes from Discussions • Redesign of biased radioactive decay • what is biasing? • allowing RDM only in certain volumes • integrating over unobserved particles (fast beta, e.g.) • emphasizing specific branching ratios • sampling rates, weights within time windows • collimation • implementation • make a non-biased version of RDM process • wrap it in biasing class • move all current biasing methods to wrapper • develop UI commands for configuring biasing

22. Notes from Discussions • Redesign of biased radioactive decay • tallying of histories should be done by scorers • attach scorer to process • input source time profiles by macro (not data or histogram file) • must be able to collect activities using Bateman equations

23. Use Cases and Requirements for Biasing • Activation in radiation detectors • spacecraft • in beam line shielding • Decay chains in low background experiments • Radioactive source simulations • specify source activity and time (DAQ) window • make UI command for this • source profiles • Radiotherapy • observation of decay within energy or time windows (in beam imaging) • Examine biasing options in MCNP, FLUKA

24. Use Cases and Requirements for Biasing • Isotope production • splitting • branching ratio biasing • Backgrounds due to accidental coincidences • PET • rare decays with gammas • Total dose, pulse height tallies • Integrating un-observed particles • fast beta decay • when neutrinos or other particles are not needed • GUI for nuclide tables

25. Use Cases and Requirements for Biasing • Weight window for branching ratio biasing • to replace existing option for equal branching ratios • Specification of ranges in (A,Z) • list of (A,Z,E) • specify levels by time limit (minimum time?) • Retain attachment to volumes • currently logical volumes – what about physical? • do this within process

26. Tasks • Martin Venhart • examine 92 known floating levels to see if existing data can be used to fix them • contact T. Kibede to see if Geant4 may use his atomic relaxation code • Laurent Desorgher • add column in photon evaporation database for multi-polarity and delta • add beta-delayed neutron data to database • Alberto Ribon • test for thread saturation in random number generation • Alex Howard • continue testing of random number generators

27. Tasks • Makoto Asai • add character argument to ions, as well as Get, Find, Create methods • attach scorer to process (for biasing) • work on binary database implementation • Andrea Dotti • test for thread saturation in random number generation • work on binary database implementation • Dennis Wright • make RDM model for testing which has all biasing code removed • replace G4UAtomicRelaxation with G4VAtomicRelaxation • implement double beta decay using spectrum from Luciano Pandola • Marc Verderi • check correctness of generic biasing in both at-rest and in-flight modes

28. Tasks • Luis Sarmiento • write code for beta-delayed neutron channel • Unassigned • check lower limit on life time (10e-14 ?) 9B decays • develop new RDM example (rdecay03) to demonstrate new decay channels • according to XEON-Phi tests Geant4 is now CPU-bound -> general improvement in coding is required • allow assignment of RDM to G4Region as well as G4LogicalVolume

29. Design Teams Floating Levels • Makoto Asai • Martin Venhart • Tatsumi Koi • Vladimir Ivantchenko • Laurent Desorgher Biasing • Marc Verderi • Alex Howard • Luis Sarmiento • Dennis Wright • Giovanni Santin • Makoto Asai • Laurent Desorgher

30. Design Teams Beta-delayed neutrons • Luis Sarmiento • Laurent Desorgher • Dennis Wright Random Numbers • Alex Howard • Alberto Ribon • Andrea Dotti