Greetings to the community,
I’ve tried to run the test RDX run located in examples/reax but got a crash of the run with these several warnings appearing:
Looks like a memory error - I'll have the ReaxFF folks
look into it.
Steve
Just posted a 26Jan12 patch that fixed a memory
error in Reax/C. Isn't necessarily related
to the error you are seeing, but we see no memory
errors now running the examples/reax/in.reaxc.rdx.
Please check if you still do.
Steve
Hi Steve,
It still persists. Whenever I'm trying to restart an nve simulation from a
minimization run (binary restart file) , I get the error messages.
When reading a data file, instead of restart file (e.g using rest2data), I
see no errors.
Something to do with reading binary restart files with the new version ?
2012/1/29 David Furman <[email protected]...>:
Hi Steve,
It still persists. Whenever I'm trying to restart an nve simulation from a
minimization run (binary restart file) , I get the error messages.
When reading a data file, instead of restart file (e.g using rest2data), I
see no errors.
yes. the problem results from some technical issues
of how memory management of the reax/c support code
handles memory management. it is pretty straightforward
to track it down with a debugger. please try out the attached
version of the pair_reax_c.cpp file to replace yours. that
should make reax/c in lammps work properly with restarts
and related procedures.
you don't need to use a restart, but simply the
following two statements (before the first run or minimize)
will suffice:
pair_style reax/c
pair_style none
Something to do with reading binary restart files with the new version ?
i don't think that this has something to do
with the new version, but it is more likely
that it had not been fully tested. none
of the examples are using the restart feature.
cheers,
axel.
pair_reax_c.cpp.gz (5.56 KB)
Hey Axel,
It seems that the new file solves the bug.
Can you please explain what specifically was wrong with the original memory
management ? (a newbie here)
I've noticed you added another conditional in the new pair_style
2012/1/30 David Furman <[email protected]...>:
Hey Axel,
It seems that the new file solves the bug.
Can you please explain what specifically was wrong with the original memory
management ? (a newbie here)
the problem that my patch is trying to fix is that the code in
the destructor is assuming that you had called Pair::setup()
before deleting the class. this is what happens normally.
however, after restarts or the example i gave, this is not true
and thus the error messages.
I've noticed you added another conditional in the new pair_style
yes. the infrastructure to do "the right thing(tm)" had been implemented,
but was used to avoid doing the low-level one time memory allocation
multiple times and thus leak memory. all i needed to do was to take
advantage of it for the opposite case, i.e. avoid that it is freed when it
was not yet allocated.
cheers,
axel.
Just added this fix to the repo - will
be in the next patch as well ...
Thanks Axel ...
Steve