The OPAL Discussion Forum

[Adelmann Andreas <andreas.adelmann AT psi.ch>]

Hi Chris, thank you so much for the flowers and reporting the bug will open an issue today.

Maybe we can add your fix this to the 2023.1 release. Please send me the changed file so I can

see exactly what you did!

 

Cheers and many thanks  Andy 
------
Dr. sc. math. Andreas (Andy) Adelmann
Paul Scherrer Institut OHSA/D17 CH-5232 Villigen PSI
Phone Office: xx41 56 310 42 33 Fax: xx41 56 310 31 91
Zoom ID: 470-582-4086 Password: AdA
Zoom Link: https://ethz.zoom.us/j/4705824086?pwd=dFcvT1pMMGY0bHg0dTNncUNZZTJkZz09

-------------------------------------------------------
Friday: ETH HPK G 28   +41 44 633 3076
============================================
The more exotic, the more abstract the knowledge, 
the more profound will be its consequences.
Leon Lederman 
============================================

On 27 Nov 2023, at 17:00, Christopher Pierce <cmpierce AT uchicago.edu> wrote:

Hey folks,

I have been using OPAL for some space charge particle tracking on a recent project and have been having a great experience with it so far. Thanks for the nice code!

One thing I ran into recently is an out-of-memory issue when I run it with many "monitor" elements. What seems to be happening is that the memory allocated while saving the particles to disk doesn't get freed after the file is output. In my case, I was using 2 million particles and I could see the memory usage rise by 200MB as the first monitor output is saved to disk and then rise by another 200MB at the second and so on. Since I was producing video-like output with 48 monitors, it didn't take long to exceed our cluster's 4GB per core limit.

I did some digging in the source code and on line 367 in `src/Classic/Structure/LossDataSink.cpp` I saw that the vectors storing particle information in the monitor objects do get cleared. Reading online, though (since I'm not a C++ expert) I saw some people saying this might not free memory (https://stackoverflow.com/questions/13944886/is-stdvector-memory-freed-upon-a-clear). I implemented their suggestion, ie the following code to replace all of the clear methods.

std::vector<OpalParticle>().swap(particles_m);

std::vector<size_t>().swap(turnNumber_m);

std::vector<size_t>().swap(bunchNumber_m);

std::vector<double>().swap(spos_m);

std::vector<double>().swap(refTime_m);

std::vector<Vector_t>().swap(RefPartR_m);

std::vector<Vector_t>().swap(RefPartP_m);

std::vector<h5_int64_t>().swap(globalTrackStep_m);

After recompiling the code, the memory growth seems to have gone away and I can run it on the cluster again without going over our RAM limits.

I wanted to pass this along to see if it's the right thing to do to deal with the memory problem I was having and also in case  anyone else finds it useful.

Cheers,

Chris

​