Hi,
I am doing cascade simulation using LAMMPS. I have used Periodic
Boundary Condition (PBC) for this calculation. It is well understtod
that in PBC whenever an atom goes outside the MD simulation box it
should appear on the other side within the box. Therefore, if initial
coordinates of atoms fall in between, say, 0 to L (where 0 is taken as
origin), using PBC we should expect the coordinates of the atoms will be
always with in the box, i.e. it can not be negetive or greater than L.
But, In my calculation (in dump file), I am getting some coordinates
negetive and some coordinates greater than box length.
My question : Why is it so?
Does LAMMPS use PBC only during the force calculation and
during printing coordinates it does not do so?
Regards.
Prithwish Nandi
You may see coords slightly outside the box, b/c LAMMPS
only enforces PBC every few steps, which may not coincide
with the timestep the snapshot was written. The doc
page for the dump command explains this.
Steve
Hi,
I have seen the dump docs in manual. The following is mentioned :
"IMPORTANT NOTE: Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an atom
written to a dump file may be slightly outside the simulation box."
As far as I understand, neighbor lists are rebuilt by the following
commands in the INPUT file.
neighbor and neigh_modify
I have used the following settings :
neighbor 1.0 bin
neigh_modify delay 0 every 1 check yes
Therefore, I am updating the neighbor lists every time step and the
coordinates should be always with in the simulation box whenever I am
dumping it.But I am not getting this.
This does not seem to be alright.
Well, this
neigh_modify delay 0 every 1 check yes
means that your neighbor lists are probably not being built
every step. Because of the check yes command, they are only
being built on steps when an atom has travelled more than half
the skin distance. Read the documentation for more details.
Joanne Budzien
Hi,
hi prithwish,
I have seen the dump docs in manual. The following is mentioned :
"IMPORTANT NOTE: Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an atom
written to a dump file may be slightly outside the simulation box."
As far as I understand, neighbor lists are rebuilt by the following
commands in the INPUT file.
neighbor and neigh_modify
I have used the following settings :
neighbor 1.0 bin
neigh_modify delay 0 every 1 check yes
Therefore, I am updating the neighbor lists every time step and the
coordinates should be always with in the simulation box whenever I am
you have to set 'check no' to force rebuilding the neighborlists.
dumping it. But I am not getting this.
perhaps it would be more helpful (to you?) to explain why you
are so obsessed with getting exactly PBC wrapped coordinates.
whether you do the neighborlist rebuild more often or not,
the computed interactions remain the same (modulo small differences
due to summing up floating point numbers in different order).
please have a look at the domain decomposition scheme that
LAMMPS employs and it should be evident. rebuilding the
neigborlists is quite time consuming and doesn't parallelize
too well, so rebuilding them more often will result in a severe
performance hit and less parallel scaling. it would be _much_
simpler and more efficient to wrap the coordinates back in
prostprocessing, (especially, if you use a binary trajectory
format).
cheers,
axel.
Hi,
May I know, what I am doing wrong here to get an error message as " ERROR:
Per-atom virial was not tallied on needed timestep".
Below is the part of input file, which should be of interest.
Cheers,
Dhiraj
---------PART OF INPUT FILE-----------
......
........
.........
compute peratom all stress/atom
compute p all reduce sum c_peratom[1] c_peratom[2] c_peratom[3]
variable press equal -(c_p[1]+c_p[2]+c_p[3])/(3*vol)
variable sig11 equal -c_p[1]/vol
variable sig22 equal -c_p[2]/vol
variable sig33 equal -c_p[3]/vol
thermo_style custom step temp v_press v_sig11 v_sig22 v_sig33
thermo 1
dump 2 all atom 10 atomFILE
run 100
-------------XXXXXX--------------------
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3791 (20090122) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Are you running the current, fully patched LAMMPS?
A couple bugs on this have been fixed since 9Jan09.
Steve
Thanks steeve,
Its working fine with the current, fully patched LAMMPS.