[lammps-users] reax/c Restart Files

LAMMPS LAMMPS Mailing List Mirror
1

Axel,

I've attached the input scripts to reproduce the error. First I run in0.script which will generate restart files. Then I grab 100.restart and run in1.script (which is the same as in0.script except for a read_restart command instead of the read_data command). This gives me a segmentation fault error.

Let me know if you need anything else.

Ben Jensen
Computational Mechanics & Materials Research Laboratory
Mechanical Engineering - Engineering Mechanics
Michigan Technological University
Houghton, MI

in0.reax (1.23 KB)

struc.data (7.88 KB)

in1.reax (1.24 KB)

ffield.reax (19.6 KB)

2

hi ben!

Axel,

I've attached the input scripts to reproduce the error. First I run in0.script which will generate restart files. Then I grab 100.restart and run in1.script (which is the same as in0.script except for a read_restart command instead of the read_data command). This gives me a segmentation fault error.

ok. thanks. that is _perfect_!

i have been able to identify the reason for the segfault
(despite never having used reax/c before myself).

there is a simple but unelegant workaround:
just insert a

reset_timestep 0

before the run statement. there is a heuristic in pair_reax_c.cpp
that determines whether it needs to allocate memory, that doesn't
work if the initial timestep number is not 0.

i'll see if there is a simple way to fix this properly without having
to dig too deep into the internals of the code.

cheers,
    axel.

3

hi ben!

Axel,

I've attached the input scripts to reproduce the error. First I run in0.script which will generate restart files. Then I grab 100.restart and run in1.script (which is the same as in0.script except for a read_restart command instead of the read_data command). This gives me a segmentation fault error.

ok. thanks. that is _perfect_!

i have been able to identify the reason for the segfault
(despite never having used reax/c before myself).

there is a simple but unelegant workaround:
just insert a

reset_timestep 0

before the run statement. there is a heuristic in pair_reax_c.cpp
that determines whether it needs to allocate memory, that doesn't
work if the initial timestep number is not 0.

ok. here is my suggestion for a change.
overall it looks a bit suspicious to have this in ::compute()
and particularly to only run the guessed allocate once and
not the reallocate throughout the run. even without knowing
much about the actual implementation, i would be expecting
this to lead to memory corruption or worse for some inputs.

diff --git a/src/USER-REAXC/pair_reax_c.cpp b/src/USER-REAXC/pair_reax_c.cpp
index 8191dbf..cc2f71c 100644
--- a/src/USER-REAXC/pair_reax_c.cpp
+++ b/src/USER-REAXC/pair_reax_c.cpp
@@ -331,7 +331,9 @@ void PairReaxC::compute(int eflag, int vflag)
   system->big_box.box_norms[2] = 0;
   if( comm->me == 0 ) t_start = MPI_Wtime();

- if( update->ntimestep == 0 ) {
+ // XXX: shouldn't initialization go into settings() or something?
+ // AK: 2010/11/15
+ if( system->my_atoms == NULL ) {
     control->vlist_cut = neighbor->cutneighmax;

     // determine the local and total capacity

cheers,
     axel.

4

I changed the restart2data tool to add support for reax/c.
I'll have Aidan work with the Reax/C developer on the
restart crash issue. I agree with Axel that the setup
code shouldn't be in compute() and it shouldn't be
assuming the timestep = 0. But I don't know
what all he is expecting to (re)initialize, so I'll let
them work it out.

Steve

5

I added a setup function that is only called the first time. I also added a
check for non-existent requested types. It is valgrind-clean. I committed to
svn.