Hi Steve,
Back in March 1, 2012 we discussed a problem I had with memory leaks when using reaxc through iterative calls to the lammps library. At the time, I worked around the problem by avoiding the large iteration count that led to allocation failure.
I’ve read some threads about this on the lammps user’s list, and I believe Ray had pointed to a problem when using fix_qeq for which he proposed a solution.
In any case, I wanted to check back on this, so I went ahead and ran the following two cases from the examples provided in the LAMMPS distribution, one directly through lammps executable and one through a lammps library call, using LAMMPS (30 Sep 2013):
-
mpirun -np 1 valgrind -v --leak-check=full ./lammps-30Sep13/src/lmp -in in.reaxc.rdx (from /examples/reax)
-
mpirun -np 1 valgrind -v --leak-check=full ./lammps-30Sep13/examples/COUPLE/simple/simple 1 in.reaxc.rdx (from /examples/COUPLE/simple … BTW, all instances of lmp need to be changed to ptr in the simple.c file, in order for it to compile properly)
This simple.c code is linked via a dynamics .so lammps library.
Both cases, ran with “-v --leak-check=full” in valgrind 3.8.1, return a few apparent leaks that I would like to confirm with you guys (I’ve tried this with the latest openmpi, configure with valgrind option, and the latest mpich2). In the 1st case, lost blocks point to LAMMPS_NS::NeighList::setup_pages and in the 2nd mostly to Make_List.
Let me know if you are able to replicate these problems.
Best regards,
Andres Jaramillo-Botero
California Institute of Technology