Segmentation fault when using fix move

LAMMPS LAMMPS Mailing List Mirror
1

I’ve been getting a segmentation fault when I try to run fix move in the following script,

(I’m simply trying to have a fixed velocity on each individual atom in the group “outer”. I’d like to run the rest of the atoms as a typical NVT simulation.)

CuO PacMan for COMB3 potential

units metal
atom_style charge
atom_modify map array
boundary p s s
read_restart restart.20900.92_14

variable uy atomfile VY.in
variable uz atomfile VZ.in
variable ux atomfile Vx.in
variable xa atom v_ux
variable ya atom v_uy
variable za atom v_uz
region lips cylinder x {CY} {CZ} 55 0 EDGE units box side out
region inside cylinder x {CY} {CZ} 55 0 EDGE units box side in
group outer region lips
group in region inside

mass 1 63.546
group type1 type 1
compute charge1 type1 property/atom q
compute q1 type1 reduce ave c_charge1
mass 2 16.00
group type2 type 2
compute charge2 type2 property/atom q
compute q2 type2 reduce ave c_charge2

pair_style comb3 polar_off
pair_coeff * * …/…/…/potentials/ffield.comb3 Cu O
neighbor 0.2 bin
neigh_modify every 1 delay 0 check yes

timestep 0.001
thermo_style custom step temp etotal pe evdwl ecoul c_q1 c_q2 press vol
thermo_modify norm yes
fix m outer move variable NULL NULL NULL v_xa v_ya v_za
velocity in create 5.0 3482028
fix 1 in nvt/omp temp 5.0 5.0 0.1
fix 2 all qeq/comb 1 0.001 file fq.min.out

#dump myDump all custom 10 dump.CuO.crack id type x y z q

write_dump all custom dump.test id v_xa v_ya v_za

restart 100 restart.*.94_14
thermo_style custom step temp etotal pxx cpu vol
thermo 1
#minimize 1e-6 1.0e-6 100000 200000
run 1

The following is returned by all MPI grids:

[Neo:09479] *** Process received signal ***
[Neo:09479] Signal: Segmentation fault (11)
[Neo:09479] Signal code: Address not mapped (1)

When I look at the write_dump file each of my xa, ya, za variables comes out to the correct values, and the atomfile input files are the correct format. If I remove the fix move, I no longer get a segmentation fault.

I’m running LAMMPS from 15 August 2014 on Ubuntu.

Any ideas why this is happening/options to avoid it?

Mike

2

mike,

a segmentation fault is a very generic error and can be cause by
multiple things.

can you try to pick one of the inputs in the examples directory and
apply fix move to it in a similar fashion so that you get the
segmentation fault again. it is going to be difficult to track this
down without a fast and simple way to reproduce this.

axel.

3

A timestep of 1fs is simply too large - try 0.2 or 0.1 fs.

What are your ux, uy, and uz?

Ray

4

Thanks for the input-- I’ve put together a simpler example from the in.comb3 example file, in the example/comb folder, which produces the same error when I use fix move (segmentation fault, address not mapped).
In this file all I did was make region selections for atoms that had Z values greater than 20 Angstroms. I have an atomfile input file for a velocity distribution (Vx, Vy, Vz) with a format as follows,

Vz.in:

4 2.107100e-05
6 2.272780e-05
7 2.454390e-05
16 2.453990e-05
17 2.108210e-05
22 2.452810e-05
24 2.454110e-05
30 2.108910e-05

…

These are only for the indices with Z greater than Z=20 Angstroms.

I attached the files for convenience.

My goal is to assign these Z velocities to the atoms in the defined region ( Z > 20).

The input file is as follows,

Graphene-OH on Cu2O (110) surface

units metal
atom_style charge
atom_modify map array
dimension 3
boundary p p p

read_data data.comb3-OHCCu

get velocity data

variable ux atomfile Vx.in
variable uy atomfile Vy.in
variable uz atomfile Vz.in
#assign regions
region 1 block 0 INF 0 INF 20 INF side in
region 2 block 0 INF 0 INF 20 INF side out

group upper region 1
group lower region 2

mass 1 16.0
mass 2 63.5
mass 3 1.00
mass 4 12.0
mass 5 12.0

pair_style comb3 polar_off
pair_coeff * * ffield.comb3 O Cu H C C

neighbor 2.0 bin
neigh_modify every 1 delay 0 check yes

#dump 1 all cfg 10 *.cfg mass type xs ys zs id type q
#dump_modify 1 element O Cu H C C
velocity lower create 5.0 111111

#fix 1 lower nvt temp 5.0 5.0 0.1
fix 1 lower nve
fix 2 all qeq/comb 10 1e-3 file fq.out
fix 3 upper move variable NULL NULL NULL v_ux v_uy v_uz

timestep 0.00010

thermo_style custom step temp etotal pe evdwl ecoul press vol lx ly lz
thermo_modify norm yes
velocity all create 300.0 2398378
thermo 10
run 100

Once again this will run correctly when I don’t include the move fix. My ux, uy, uz values come out correctly when I dump them. Also Ray–in my original problem the values of uy, uz are of order 10^-5 and the ux is zero. In this problem ux, uy are zero and uz is of order 10^-5. I used a much smaller timestep to no avail. I tried substituting each of the files with all non zero values and this did not work either. Can the issue be with the atom_modify map array command ? I need the command to use atomfile variable types.

in.comb3 (1.08 KB)

Vx.in (1.03 KB)

Vx.in (1.03 KB)

Vz.in (2.22 KB)

5

Thanks for the input-- I've put together a simpler example from the in.comb3
example file, in the example/comb folder, which produces the same error when
I use fix move (segmentation fault, address not mapped).
In this file all I did was make region selections for atoms that had Z
values greater than 20 Angstroms. I have an atomfile input file for a
velocity distribution (Vx, Vy, Vz) with a format as follows,

thanks. this is indeed a bug in fix move and with the provided files,
it was easy to track it down.
some of the initialization needs to be shuffled around and variables
properly initialized.
please find attached a corrected version of fix move that runs the
input without a segfault.

axel.

fix_move.cpp.gz (5.53 KB)