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);