Fix atom/swap issue

Dear Lammps Community,

We have been trying to use “fix ID group-ID atom/swap” for MC and every time got segmentation fault error, I started topic here

I will appreciate any working sample of using fix atom/swap command.

Best Regards,
Ilya Karkin

Dear Lammps Community,

We have been trying to use "fix ID group-ID atom/swap" for MC and every time
got segmentation fault error, I started topic here
LAMMPS download |

but you failed to provide sufficient information that allows to track
this down. your post is missing the data file and you did not specify
with which version of LAMMPS under what conditions this happens and
whether this behavior is reproducible with the very latest LAMMPS
patchlevel (development) version. nobody wants to track down a bug
that may have already been fixed and the barrier to try to reproduce
an issue is pretty high, if the input deck in incomplete.

I will appreciate any working sample of using fix atom/swap command.

your example in your previous post is quite wrong in many rather
fundamental issues so that it a) does do a lot of things that don't
make sense or should not be done and b) cannot - as a matter of
principle - produce any meaningful results. you define a loop, but all
you do inside that loop is to (re-)define the fix and some variables.
that doesn't do anything, since there is no propagation of atoms. if
you read the documentation of how fixes work and particularly how fix
atom/swap is only invoked in the frequency that is given in the
command line, it should become clear that you are not achieving
anything with this (outside of exposing potential memory leaks, yet i
cannot find any with the latest development version of LAMMPS).

please find below a modified version of the melt example from the
LAMMPS distribution, that demonstrates the intended use of fix
atom/swap. it defines as bulk system with two slightly different LJ
atom types in two halves of the system and uses fix atom/swap to
accelerate mixing of the atoms.

units lj
atom_style atomic

lattice fcc 0.8442
region box block 0 10 0 10 0 10
region half block 2.5 7.5 0 10 0 10
create_box 2 box
create_atoms 1 box
set region half type 2
mass 1 1.0
mass 2 2.0

velocity all create 3.0 87287

pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
pair_coeff 1 2 0.95 1.1 2.5
pair_coeff 2 2 0.9 1.2 2.5

neighbor 0.3 bin
neigh_modify every 2 delay 2 check yes

fix 1 all nve
fix 2 all atom/swap 25 10 98765 1.5 types 1 2

thermo_style custom step pe ke f_2[1] f_2[2]
thermo 25
run 2500

Dear all,

I had a look at the new styles of compute chunk/atom, bin/sphere and
bin/cylinder, and think that, if my understanding is right, they would
need to apply the minimum image convention when calculating distances
for binning, as the origin position for the bins is fixed and therefore
leads to distances larger than half the box length when the distances to
this origin are calculated without applying the minimum image convention.

My suggestion to fix this is found in the diff below.
(LAMMPS version used is 19 Dec 2015, original/compute_chunk_atom.cpp
refers to this, modified/compute_chunk_atom.cpp is my suggestion. The
error checks I used are commented out.)

Best wishes,

Martin Wagner
(FZ Juelich, Germany)

[email protected]...:~/.../contribute/chunk_atom$ diff -c
original/compute_chunk_atom.cpp modified/compute_chunk_atom.cpp
*** original/compute_chunk_atom.cpp 2015-12-23 09:36:17.418136196 +0100
--- modified/compute_chunk_atom.cpp 2015-12-23 10:23:49.294190902 +0100

When I wrote this I didn’t imagine anyone would
want to use it with radii > 1/2 box size for a periodic system.
I’m not clear
what it means to have spherical (or cylindrical)
bins for a periodic system. What if the user specifies
a radius that is 10x the periodic box length?
Even for a radius that is between 1/2 and 1.0 times
the box length, I don’t see much utility in values
where it is ambiguous which bin the atom should be in.
Things like density where you have # of atoms/volume
seem like they will be wrong, or at least give
unexpected values. Maybe it would be useful to have
an option where you could specify a radius > box size
and a single atom would be tallied to multiple bins, i.e.
all the ones that it falls into. Then you could get values
as a function of r that would be similar to what you’d get
if you embedded spherical bins in an infinite bulk system.
However, that logic is counter to the chunking that
LAMMPS uses, since each atom is assigned a single
unique chunk ID (bin # in this case).

Currently, I think of the bins as a geometric object that you overlay
on your simulation box. It is up to you to insure the bins
are populated with atoms in a way that makes sense
for the stats that are being tallied. Kind of like the way
regions are defined, which are also not periodic.

But I’m open to suggestions. Regardless
the behavior should be clearly documented, which
it isn’t yet.


Even if my maximum radius is 1/2*box size, I still see problems as soon as my box is not cubic and the sphere origin is not the center of the box.
Or, if I really want to bin all atoms in my system, I choose a radius equal to half the maximum box diagonal.

I did a small test case to show this.
The input script is a slight modification of the melt-example (found below), the error check is found in the appended diff.

Running it, it gives me the following output:

box half lengths: 16.795962 16.795962 16.795962
position of atom to bin 19.315356 0.839798 0.000000
sphere bin origin 1.679596 1.679596 1.679596
r without minim = 17.735454
r with minim = 16.066284
ERROR: error here (../compute_chunk_atom.cpp:1787)

This is the case when my sphere origin is at the lower left of the box, and it would need to bin atoms on the other side of the periodic boundaries.

To be honest, I cannot come up with a real use case for spherical binning with a fixed origin and periodic boundaries myself at the moment, I just stumbled upon this while trying to implement the same for a moving origin, e.g. to measure a temperature field around one specific atom.

Best wishes,

Martin Wagner

Input Script:

# 3d Lennard-Jones melt
variable x index 1
variable y index 1
variable z index 1
variable t index 100
variable xx equal 20*$x
variable yy equal 20*$y
variable zz equal 20*z units lj atom\_style atomic lattice fcc 0\.8442 region box block 0 {xx} 0 \{yy\} 0 {zz}
create_box 1 box
create_atoms 1 box
mass 1 1.0
velocity all create 1.44 87287 loop geom
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
neigh_modify delay 0 every 20 check no
fix 1 all nve

compute mychunk all chunk/atom bin/sphere 1 1 1 0.0 $(xhi/2.0) 20
fix myavechunk all ave/chunk 1 $t $t mychunk density/number file profile.dat
dump mydump all custom 10 dump.lammpstrj id x y z vx vy vz

thermo 100
run $t

Diff for the error check:

[email protected]...:~/.../contribute/chunk_atom$ diff -c original/compute_chunk_atom.cpp error_check/compute_chunk_atom.cpp
*** original/compute_chunk_atom.cpp 2015-12-23 09:36:17.418136196 +0100
--- error_check/compute_chunk_atom.cpp 2015-12-28 19:04:18.298715038 +0100