OPAL Monitor Memory Usage
Summary
(Summarize the bug encountered concisely) 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.
Steps to reproduce
Run simulation with 2E6 particles and 48 monitors
What is the current bug behavior?
out of memory
What is the expected correct behavior?
no out of memory
Relevant logs and/or screenshots
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.
Possible fixes
std::vector().swap(particles_m); std::vector<size_t>().swap(turnNumber_m); std::vector<size_t>().swap(bunchNumber_m); std::vector().swap(spos_m); std::vector().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);