Pre- coumpound /de-excitation progress

1. Pre-coumpound/de-excitation progress V.Ivanchenko 25 January 2012

2. Outline • Creation and deletion of pre-comound/de-excitation objects • New gamma evaporation • Comments: • Jose Manuel, Anton and me have discussed possible work plan for 2012 for pre-compound/de-excitation • My part is mainly infrastructure, which I was trying to work in the beginning of January • Some discovery require discussion and model developers should be informed

3. What pre-compound/de-excitation models do? • The pre-compound model get as an input G4Fragment object which include all information about excited nuclear fragment and return list of secondaries after de-excitation • Both pre-compound and de-excitation do not know about high energy generator was used • Pre-compound model holds a pointer to G4ExcitationHandler which is responsible for equilibrium de-excitation and also holds pointers to pre-compound channel classes • G4ExcitationHandler include pointers to G4MultiFragmentation, G4FermiBreakUp, G4Evaporation, G4PhotonEvapration • Each of sub-channels have many classes to describe nuclear decays • In total about 300 tiny objects are instantiated in memory at initialisation and many run time objects (vectors of probabilities, ….) • In Geant4 9.5 this ZOO was not properly deleted at the end of the job • Gabriele valgrind log file is huge with thousands of error messages • Total memory lost is about 800k for FTFP_BERT • There are many identical instances created differently inside different models and physics builders,

4. Current Status • Why the problem appears? • Because we did not have clear rule who can create and who should delete pre-compound/de-excitation objects • We create too many identical objects, how to avoid this? • Different objects is needed only if extra options should be configured • For majority of models instantiated by physics builders we should provide a way to get a pointer of centrally instantiated G4PreCompoundModel • Current solution (all valgrind reports about pre-compound/de-excitation are fixed): • G4PreCompoundModel* preco = new G4PreCompoundModel(); • G4ExcitationHandler* hand = preco->GetExcitationHandler(); • G4GeneratorPreCompoundInterface* gpi = new G4GeneratorPreCompoundInterface(preco); • G4BinaryCascade* bin = new G4Binarycascade(preco) • G4BinaryLightIoncascade* bion = new G4BinaryLightIonCascade(preco)

5. Model for gamma evaporation • G4PhotonEvaporation is the old class • It is used by G4ExcitationHandler, G4Evaporation, G4RadiativeDecay, G4NeutronCaptureModel • It is based on nuclear level database which include data on probabilities of gamma emission and internal conversion • There are number of concerns to this model: • CPU, memory, correctness

6. Model for gamma evaporation • After the study my main concern is to physics: • In HEP interaction a nucleus got a bust and atomic electrons are lost • Internal conversion is not possible • It is not correct to spend time looping over conversion (K, L, M shell data – 10 channels) • Probabilities of gamma evaporation are higher due to internal conversion chains

7. New model for gamma evaporation • G4PromptPhotonEvaporation is a new class which new objects for keeping nuclear level information • Only gamma probabilities and transition energies are kept per level (6 times less memory) • Photon evaporation is active only if excitation energy of a fragment is below some threshold • less number of calls, smaller internal database on nuclear levels • Old G4PhotonEvaporation unchanged and should be used for G4RadioactiveDecay, because at rest internal conversion is possible

8. New model for gamma evaporation • One question to discuss: • Depending on excited state lifetime the decay may be prompt or not • Physically we should create an excited ion and let him be tracked until it stop and decay via radioactive decay • If we will go to this way we may have extra CPU penalty