In my sim the memory used is always increasing, reaching values >300MB. I used valgrind's massif tool and found that most of the memory is taken by G4Allocator. You can find more details from valgrind at http://umdgrb.umd.edu/vlasisva/massif.10093.ps and http://umdgrb.umd.edu/vlasisva/massif.10093.txt I'm not using any sensitive detectors in the sim. The source code can be found in http://umdgrb.umd.edu/vlasisva/g4simdebug.tar.gz Vlasios Vasileiou
The .txt file from Valgrind is not reacheable, so I cannot verify if what reported is indeed a leak or not. In any case, in the user's application it is used: /tracking/storeTrajectory 1 in the macro used for the run. This will of course internally store all trajectories in a container using the G4Allocator. Note that the allocator will NOT release the memory at the end of each event, but will reuse it during the run. So, if a 'big' event will increase the pool, the overall size of consumed memory will increase. For this purpose, the G4Allocator provides a method ResetStorage() which can be called in the user's application at the end of a certain number of events to free-up the allocated memory and return it to the free store. To verify if indeed memory is leaked, you should compare the output of Valgrind (overall memory leaked) with two runs with different number of events (so then you can exclude the memory leaked for initialisation) I imagine that if the trajectories are not stored (flag set to 0) the memory increase will not be that relevant. Please, let us know if that fixes your problem and if so also please update the related posting on Hypernews, thanks.
The massif files are accesible now. Also for the storeTrajectory it was initial set to zero. I noticed the increased memory consumption using the zero value. I made one run with storeTrajectory 1 to see how worse the things would be and right after I zipped the project to make it available to you. I should have changed storeTrajectory back to 0. Sorry about that. One extra piece of information is that I was noticing the memory consumption with top from the start of a run. It started with 30MB and for every big event it would make a jump of the order of 100MB. The memory consumption would remain that even after these events where processed. One other thing to take note is that since I'm using corsika as the event generator, for every Geant4 event there may be up to 3000-4000 Geant4 primary particles. I'll try the ResetStorage() method of G4Allocator and tell you if it helps. Vlasios Vasileiou
In the beginning of every event, I call the ResetStorage() method (from inside my SD class) to free the memory occupied by my sensitive detectors. G4Allocator<milPMTHit> milPMTHitAllocator; milPMTHitAllocator.ResetStorage() I could verify that if I don't reset the allocated storage for the SD hits, it is always increasing as the G4Allocator doesn't release it. However, while the SD storage now starts empty for each event, the overall consumed memory by the program is still high and increasing. Maybe there are some other data,apart hits, stored in the allocator? What else? Tracks? I use storeTrajectory 0. Thanks, Vlasios Vasileiou
Also tracks are stored using an allocator, if an event produces a massive number of tracks the memory will of course increase, but would expect that it will reach a stable plateau at some point... Can you specify the system (Linux distribution) and compiler you are using ?
It does reach a plateu of about 350-400 MB, but isn't this too much? There are many tracks in the sim since it simulates cerenkov photons produced in a pond from air showers. I'm using Redhat Enterprise Linux 3 and gcc 3.2.3 with G4OPTIMISE enabled.
