[lammps-users] fix ave/atom bug with periodic boundary?

LAMMPS LAMMPS Mailing List Mirror
1

Dear Developers and Users,

I recently want to output the average positions of atoms from a simulation. So I used below input script:

avgpos.xyz (20.1 KB)

2

However, from the visualized dump file, I found that some atoms appeared at
suspicious positions along the central line of the domain. So I doubt it's
because of a bug associated using ave/atom with periodic boundary. Please
let me know if it's true. Thanks

I don't know. To debug I would want to know a particular averaged atom
position that you think is wrong based on the set of instantaneous
positions it was averaged over. I.e. compute the average by
hand for a simple problem and show me that the code isn't producing
that answer.

Steve

3

Please see the attached. I created a cubic box with an atom at the edge, then by applying a constant velocity, I pushed the atom to cross the periodic boundary. If you look at the avgpos.dump, you will see the average position is about the center of the cubic box, which should not be reasonable. Considering the purpose of periodic boundary condition, the actual average position should be somewhere near the initial position in this test case. Thanks

Bo

aveatom.rar (25.9 KB)

4

Dear Developers and Users,

I recently want to output the average positions of atoms from a simulation.
So I used below input script:

=================
units metal
dimension 3
boundary p p s
atom_style atomic
neighbor 2.0 nsq
pair_style airebo 3.0 1 0
read_data lammps.txt
pair_coeff * * CH.airebo C
velocity all create 300 102436 mom yes rot yes dist gaussian
timestep 0.001
thermo_style custom step temp lx ly lz press pe ke
thermo 10000
fix NPT all npt temp 300 300 0.01 x 0.0 0.0 0.1 y 0.0 0.0 0.1
run 400000
unfix NPT
fix NVE all nve
run 200000
reset_timestep 0
dump 1 all custom 10 spect.bin id vx vy vz
fix apos all ave/atom 10 100000 4000000 x y z
dump 3 all custom 4000000 avgpos.dump id f_apos[1] f_apos[2] f_apos[3]
run 4000000

However, from the visualized dump file, I found that some atoms appeared at
suspicious positions along the central line of the domain. So I doubt it's
because of a bug associated using ave/atom with periodic boundary. Please

aren't x, y, and z always _supposed_ to be inside the
principal simulation box (modulo re-neighboring)?

have you tried using xu, yu, and zu instead. those should refer
to the unwrapped positions (at least in dump output).

axel.

5

Dear Axel,

Thanks for the info! However, I tried xu, yu, zu, it's not supported by fix ave/atom command.
ERROR: Illegal fix ave/atom command

Is there some easy way to do xu, yu, zu for fix ave/atom? Thanks!

Bo

6

Dear Axel,

Thanks for the info! However, I tried xu, yu, zu, it's not supported by fix
ave/atom command.
ERROR: Illegal fix ave/atom command

Is there some easy way to do xu, yu, zu for fix ave/atom? Thanks!

i can have a look. should not be too complicated.
the tricky part is to get it right for tilted cells, but i
have done this before with dump styles, so i should
have code fragments that work for those cases.

axel.

7

That's wonderful! I'll be looking forward to the patch! Thank you so much for this!

Bo

8

You can use any per-atom quantity, including xu, etc, with fix ave/atom
if you use compute property/atom for xu, etc. and then and use that
compute as the
input to fix ave/atom.

Steve

9

Dear Steve,

That seemed to solve the problem. Thanks!

Bo