Hi.
One of our users is having problems running the attached script over
72 processors on our Linux Cluster (using Open MPI 1.4.1).
At step 84 it dies with a segmentation violation in function Pair::v_tally3:
vatom[k][0] += v[0]; vatom[k][1] += v[1]; vatom[k][2] += v[2];
with k = 140085
I've had a go at tracking it down and found the following:
The problem appears to be it accessing a region outside of vatom.
At the start of the run atom->nmax =140000. vatom is allocated to this
size (vatom[140000][6]).
At step 84 atom->nmax increases to 150000. Several of the atom arrays
are increased in grow() as called from here:
Verlet::run calls comm->borders() line 225
Comm::borders call avec->unpack_border() line 773
AtomVecAtomic::unpack_border
for (i = first; i < last; i++) {
if (i == nmax) grow(0);
calls grow(), where atom->tag, atom->type, atom->mask and atom->image
are resized,
but the size of vatom is not increased.
Shortly afterwards PairTersoff::compute then calls v_tally3 in
pair.cpp which tries to access index 140085 which is beyond the
bounds of vatom (still sized at 140000).
Are doing something wrong in our input script or is this a bug?
Thanks,
Duncan
SiC_Erhart-Albe.tersoff (1.56 KB)
in.fail (1.42 KB)
duncan,
which version of lammps are you using?
can you generate an input that has the same
problem but uses less atoms?
does the crash depend on the number processors?
Hi.
One of our users is having problems running the attached script over
72 processors on our Linux Cluster (using Open MPI 1.4.1).
At step 84 it dies with a segmentation violation in function Pair::v_tally3:
vatom\[k\]\[0\] \+= v\[0\]; vatom\[k\]\[1\] \+= v\[1\]; vatom\[k\]\[2\] \+= v\[2\];
with k = 140085
I've had a go at tracking it down and found the following:
The problem appears to be it accessing a region outside of vatom.
At the start of the run atom->nmax =140000. vatom is allocated to this
size (vatom[140000][6]).
At step 84 atom->nmax increases to 150000. Several of the atom arrays
are increased in grow() as called from here:
Verlet::run calls comm\->borders\(\) line 225
Comm::borders call avec\->unpack\_border\(\) line 773
AtomVecAtomic::unpack\_border
for \(i = first; i < last; i\+\+\) \{
if \(i == nmax\) grow\(0\);
calls grow\(\), where atom\->tag, atom\->type, atom\->mask and atom\->image
are resized,
but the size of vatom is not increased.
Shortly afterwards PairTersoff::compute then calls v_tally3 in
pair.cpp which tries to access index 140085 which is beyond the
bounds of vatom (still sized at 140000).
that should not be a problem. since PairTersoff::compute() should
call Pair::ev_setup() which should grow vatom correspondingly.
cheers,
axel.
that should not be a problem. since PairTersoff::compute() should
call Pair::ev_setup() which should grow vatom correspondingly.
exactly - ev_setup() is called every timestep.
What makes you infer that vatom's size has not increased?
There could always be a bug in this logic somewhere.
Can you look at maxvatom and atom->nmax on the proc
that is dying when in tally3 ??
Steve
that should not be a problem. since PairTersoff::compute() should
call Pair::ev_setup() which should grow vatom correspondingly.
exactly - ev_setup() is called every timestep.
What makes you infer that vatom's size has not increased?
There could always be a bug in this logic somewhere.
Can you look at maxvatom and atom->nmax on the proc
that is dying when in tally3 ??
...unless Pair::v_tally3() would somehow be called when vflag is false.
i ran the input on my desktop(!) with 8 MPI tasks and it does
die in step 26 in Pair:v_tally3(). no time to dig any further today...
axel.
fixed the bug - see the 30 Aug patch - the v_tally() function
was being called when it shouldn't have been
Steve
