memory issues using reax/c by calling lammps as external library.

LAMMPS LAMMPS Mailing List Mirror
1

Dear Steve, Axel, Ray et al.,
I have ran into memory problems when using the reax/c implementation
while calling lammps as an external library from a driving code.
To better portrait the issue, I have minimally modified the simple.cpp
you provide with lammps by adding a loop that does the boring task
of gathering and scattering atom positions over and over for a while.
If I call the fortran reax implementation from the input file things
behave
as I expect, yet, if I chose instead to call the reax/c (combined with
the qeq fix) then the code keeps allocating memory as the executable
runs (issuing a simple "top" will show this). The issue seem to be
related to the qeq fix because the aforementioned behavior disappears
when the qeq fix is commented out and the "checkqeq no" option is
added to reax/c. Attached are the corresponding files to reproduce the
problem. Is this a shortcoming of my understanding on how to call
reax/c from external programs or something else?
I used the latest version of lammps compiled with gcc version 4.7.0 and mpich2.
Thanks,
Carlos

in.lammps_glycine (381 Bytes)

ffield.reax (39.1 KB)

control.reax_c (1.05 KB)

simple.cpp (3.22 KB)

atoms.glycine (464 Bytes)

2

Hi Carlos,

Can you add "run 0" at the end of your script and try again?

Thanks,
Ray

3

Ray,
If you meant adding "run 0" at the end of in.lammps_glycine that
didn't help. Still memory grows as the loop runs.
Carlos

4

Hi Ray (and Steve and others)
Any other suggestions related to my question? Have you at least
verified my observations?
Thanks,
Carlos

5

Hi Carlos,

I have check reax/c with fix qeq/reax with Valgrind, and no memory
leak problem was found. Maybe this error only happens with a driver
code. I will try to work this out in the next few days.

Thanks,
Ray

6

Hi Ray,
Thanks. Does that mean that you were able to see the memory increasing
by running the toy example I sent? Just trying to rule out a system
specific problem on my side and/or a missing #include statement or
something else in the way I utilized the given example.
Thanks again,
Carlos

7

Hi Carlos,

No, I haven't been able to find time to reproduce the problem you are
showing. I merely did a quick Valgrind check for memory leaks.

Best,
Ray

8

Hi Carlos,

We picked up a problem with fix qeq/reax; please find the attached and
see if this works for you.

Thanks,
Ray

fix_qeq_reax.cpp (22.5 KB)

9

Hey Ray,
Right on. Your fix solves my problem.
Thanks for looking over my request,
Carlos

10

The new version still has the null pointer dereference if this fix is
used without a reax pair style.

This patch avoids that:

255,256c249,258
< int mincap = reaxc->system->mincap;
< double safezone = reaxc->system->safezone;

11

The patch from my previous mail needs
#include "reaxc_defs.h"
to be added to fix_qeq_reax.cpp
Daniel

12

Thanks for your changes, Daniel. This will be sent to Steve.

Thanks,
Ray