The OPAL Discussion Forum

[Christopher Pierce <cmpierce AT uchicago.edu>]

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

​