Hi All, Posted this on the user forum but thought it may be suitable to document here as well. I have a lightweight test simulation available if needed. Banging my head against a wall here... I am simulating decays of Ir-192 nuclei using G4RadioactiveDecay. I am running version 4.8.0.p01 under linux (gcc 4.0.2). I am only interested in emitted photons (no need to track Augers or Betas); accordingly, I have implemented a StackingAction class (see snippet below). Now, if I have no stacking action implemented, memory usage is static; however, once I implement this class (ie kill all tracks that are not primaries (Ir-192 nuclei) or gammas) memory consumption increases rapdily. Interestingly enough, if I remove the PhotonEvaporation data from the directory given by $G4LEVELGAMMADATA this problem is not encountered. Anybody else had such a problem? Cheers, Iwan #include "StackingAction.hh" #include "G4ParticleDefinition.hh" #include "G4Track.hh" #include "G4Gamma.hh" #include "G4Electron.hh" StackingAction::StackingAction() { } StackingAction::~StackingAction() {;} G4ClassificationOfNewTrack StackingAction::ClassifyNewTrack(const G4Track * aTrack){ // //by default don't track anything G4ClassificationOfNewTrack classification = fKill; // G4bool IsGamma = false; // G4bool IsPrimary = false; // if(aTrack->GetDefinition()==G4Gamma::GammaDefinition()) IsGamma = true; // if(aTrack->GetParentID()==0) IsPrimary = true; // if(IsGamma||IsPrimary) classification = fWaiting; // return classification; // } void StackingAction::NewStage(){ } void StackingAction::PrepareNewEvent() { }
I'm going to forward this to Makoto Asai who is the expert on stacking action. If he can't find a problem, I'll look at the hadronic side.
Symptom confirmed with the user's sample code. Also confirmed that the memory also blew up even without the stacking action. The only difference was the pace. Given one event takes much shorter time for the case with the stacking action (i.e. killing decay products rather than photons), so that the pace of memory blow-up is much more remarkable. Suspicion is on a memory leak in photon evaporation process, since, as the user observed, memory usage is quite stable in case we drop G4LEVELGAMMADATA.
The problem was due to a memory leak in G4PhotonEvaporation::BreakItUp(). An std::vector was deleted but not its newed entries. The fix: In BreakItUp(), just before the lines delete armProducts; delete atomDeex; add for (size_t i = 0; i < armProducts->size(); i++) delete (*armProducts)[i];
