Hello,
I’m running triple GEM simulations and when trying to generate signals I ran into a problem. Trying to simulate electrons from one avalanche starting from the induction gap (75000 electrons): propagate them with signal calculation enabled. I’m using single plane electrode. First I tried that on one of the newest Garfield++ commits and the RAM usage increased to the point that the program was killed (I’m testing on my 16GB RAM laptop for now).
Since previously I encountered similar RAM issues after introducing multithreading for AvalancheMicroscopic (commit ac87dc707feeacc40e32ebdd0484312a6f7bfee8) I made a simple test: simulating 1000 electrons on 2 Garfield versions: newest commit (78c29d12ab158a18008e8db51eef5e593cb9a9db) and one before the multithreading was introduced (6e7773f5d6cb055f1e61a01cec52da01d693b0a7). For simplicity, on the newer version the multithreading was disabled. I was monitoring memory usage using htop.
Results:
Memory usage was roughly constant through whole execution of the program using older version of Garfield++.
For the newest version, the memory usage was gradually increasing throughout the program execution and stopped only when the simulation finished. For this small simulation it was able to finish, but with larger number of electrons this crushes the program.
I am wondering if this is Garfield++ issue in the newest versions? Is it connected to multithreading? Or maybe I need to treat the signal calculation differently in these newer versions?
Welcome to the ROOT Forum!
I’m sure @hschindl can help
Thanks for the detailed report, this isn’t caused by the multithreading commit, it’s a separate regression in TransportElectron(). A condition was added that makes every electron record its entire collision-by-collision path whenever signal calculation is enabled, even without drift-line storage/plotting. That data isn’t actually needed for the signal calculation (which uses a separate, lightweight array) and gets discarded right after, so it’s pure wasted memory, and for large avalanches with many collisions per electron, it adds up fast.
I’ve removed that condition and confirmed with a benchmark that peak memory now stays flat regardless of avalanche size, instead of scaling with electron count as before. The fix is in the branch Patch/MemoryReduction, could you re-test at your full scale, to confirm it resolves things on your end too?
Kind regards,
Djunes
Thank you for your quick reply. This fix resolves the issue: peak memory stays flat for the whole execution of the MicroscopicAvalanche for big number of electrons (I tested for 50000).
Thank you very much!
I also have a followup question:
Im wondering if i should use Microscopic or MC avalanche for propagating electrons in the induction gap for signal calculation. Could the benefits in precision of Microscopic tracking for this big number of electrons really play a role for signal calculation in comparison to MC tracking?
Thank you for your help,
Jan
Thank you for the testing! It is now merged with the main branch.
As long as the electrons are sufficiently far away from the amplification regions it is indeed more efficient to transport them in the induction and transfer regions without sacrificing any precision. This because the number of electrons will be sufficiently high that the fluctuations in their transport, which is the strength of the microscopic engine, are averaged out. It is an approach that are used in some published triple GEM studies.
Thank you for the answer!