Hello,
I would like to report an observation regarding fix bond/react and ask whether this behavior is expected or possibly indicative of a bug.
Systems tested
I tested two different polymerization systems:
-
Different chemistries
-
Different reaction templates
-
Different map files
-
Different numbers of potential reaction pairs (roughly 9× difference)
-
Different reaction counts
LAMMPS versions
Tested with:
-
LAMMPS 29Aug2024
-
LAMMPS 4Jul2026
The behavior appears essentially identical in both versions. [docs.lammps.org]
Main observation
When fix bond/react is active, memory usage grows continuously during the simulation.
This growth appears to depend primarily on the number of MPI ranks rather than on:
-
system size,
-
number of candidate reaction pairs,
-
number of successful reactions,
-
or LAMMPS version.
Example data (100,000 steps)
| MPI ranks |
Start memory |
End memory |
Growth |
| 16 |
~3.2 GB |
~4.0 GB |
~0.8 GB |
| 24 |
~4.4 GB |
~6.4 GB |
~2.0 GB |
| 32 |
~6.3 GB |
~11.7 GB |
~5.4 GB |
| 48 |
~9.4 GB |
~15–17 GB |
~6–8 GB |
Additional observations
-
The larger system (~3× more atoms, ~9× more potential reaction pairs) shows nearly the same memory growth as the smaller system.
-
Memory growth occurs even when reactions are effectively disabled (reaction probability reduced such that no reactions occur).
-
Simulations without fix bond/react do not exhibit noticeable memory growth.
-
The growth appears much more strongly correlated with MPI rank count than with reaction count or system size.
Question
Is this expected behavior of the reaction-search/bookkeeping machinery in fix bond/react, or could this indicate a memory leak (or unintended accumulation of rank-local data structures)?
I would be happy to provide additional information or reduced test cases if useful.
Thanks for this report, this is certainly not intended behavior! Can you provide a minimal example so I can reproduce this memory leak?
Update: The problem seems to be software environment (and/or hardware?) dependent.
I built the lammps executable (4Jul2026) on an HPC facility (equipped with AMD EPYC 7352 Rome processors) using gcc 13.2.0, OpenMPI 4.1.6, FFTW 3.3.10 with bundled Kokkos 5.1.0 and OpenMP. Both this and the already existing lmp executable (29Aug2024) built with the same software stack (except that this one used kokkos 4.7.01) produced the issue.
I also built recently the executable (4Jul2026) on an old desktop machine (equipped with Intel Core i7-8700) using gcc 12.5.0, OpenMPI 5.0.10, fftw-3.3.11 with the bundled kokkos and OMP and observed no memory problems.
I’m planning to do more tests with different combinations of libraries and see what causes the problem. In any case I would suspect primarily OpenMPI. I’ll prepare a minimum script that produces the issue. Where should I send it?
Thanks for this careful analysis. If you are okay with sharing the files publicly, feel free to post a link to the files in this thread, using your file-sharing platform of choice.
Did you see different behavior on the Mac? That’d be interesting since the HPC builds all showed it — if the Mac doesn’t have the problem, that’s a pretty strong signal it’s something in how the MPI bookkeeping gets allocated or accumulated across ranks.
Using a mac is not much of a distinction. In fact, macOS by itself causes a lot of strange problems because of the unusual choices of the Apple software engineers. Using Linux for testing and debugging is the recommended choice since that is what most LAMMPS developers use and what is best understood (it is also more forgiving than other platforms).
The important question is whether this is an issue with LAMMPS or with the MPI library. For that it is necessary to have a suitable reproducer input deck, so that one can make run using tools like valgrind to check for memory leaks and then run with different MPI libraries and different versions of those. The update of the OP suggests that this could be an issue of the MPI library, but without making a proper test under controlled and consistent conditions, it is only speculation.
I have uploaded a tar file here: https://drive.google.com/file/d/1i3Viz6vlzazIFtu574UVwER-V_cwoaBt/view?usp=sharing
The two directories have input and output files prepared for, and obtained from running the same crosslinking simulation (in.epoxy: 100k steps of crosslinking and 100k steps of simple NpT without reactivity). You can check my inputs, template files, submit scripts and also the outputs. While the run in the folder HPC used 7.8 GB of memory (last line of slurm-14163437.out), the run on the desktop machine consumed only 451 MB (last line of nohup.out).
Let me know if you have any further questions regarding the system, the input script, or the used hardware and software stack.