Setting charge for ewald summations

LAMMPS LAMMPS Mailing List Mirror
1

We are testing the ewald summation convergence and found that we get two different behaviors depending on how we set the charge. From the manual, the two methods for setting charge appear to be equivalent, but perhaps method 2 is incorrect. In method 1, we use atom_style charge and in method 2, we use atom_style atomic but also use

fix 1 all property/atom q

In both cases we use
set (group or type index) charge -1
set (group or type index) charge 1

to fix the values of the charges. The problem we encounter is that in method 1, the ewald sum is stable with respect to the real-space cut off, while in method 2, the ewald sum is very sensitive to the real-space cut off, not converging to the correct answer. We would appreciate your advice about what might be incorrect about our method 2. Below are listed the in.lammps and resulting ewald sums for the two cases. Thanks in advance for your advice.

Natalie Holzwarth and Ahmad Al-Qawasmeh

=======method 1 in.lammps=======================
clear

Initialize simulation box

dimension 3
boundary p p p
units metal
atom_style charge

Create geometry

lattice sc ${latconst}
region box block 0 1 0 1 0 1 units lattice
create_box 2 box

#Insert Particles: Insert ions into NaCl structure
create_atoms 1 single 0.0 0.0 0.0 units lattice
create_atoms 1 single 0.5 0.5 0.0 units lattice
create_atoms 1 single 0.5 0.0 0.5 units lattice
create_atoms 1 single 0.0 0.5 0.5 units lattice
create_atoms 2 single 0.5 0.0 0.0 units lattice
create_atoms 2 single 0.0 0.5 0.0 units lattice
create_atoms 2 single 0.0 0.0 0.5 units lattice
create_atoms 2 single 0.5 0.5 0.5 units lattice

Create groups

group A type 1 #A for anions
group C type 2 #C for cations
group ions type 1 2

Set masses

mass 1 35.45
mass 2 22.99

Set charges

set group A charge -1
set group C charge 1

Initilize velocities

velocity all set 0.0 0.0 0.0

thermo_style custom etotal pe ecoul
thermo 1

Set potentials

pair_style coul/long ${ewcut}
pair_coeff * *
kspace_style ewald 1.e-9
pair_modify table 0

variable v1 equal pe
variable v2 equal ecoul

run 0
print “lattice {latconst} {ewcut} {v1} {v2}” append sum.dat

2

We are testing the ewald summation convergence and found that we get two
different behaviors depending on how we set the charge. From the manual,
the two methods for setting charge appear to be equivalent, but perhaps
method 2 is incorrect. In method 1, we use atom_style charge and in
method 2, we use atom_style atomic but also use

you cannot use charges with atom style atomic.

axel.

3

We are testing the ewald summation convergence and found that we get two
different behaviors depending on how we set the charge. From the manual,
the two methods for setting charge appear to be equivalent, but perhaps
method 2 is incorrect. In method 1, we use atom_style charge and in
method 2, we use atom_style atomic but also use

you cannot use charges with atom style atomic.

correction. sorry.

you should indeed be able to use it with the fix property/atom
included, provided you have a new enough version of LAMMPS.
however some quick tests reveal, that there is an inconsistency in the
real-space part of the coulomb force/energy calculation for the second
option. this would require some careful debugging of how fix property
communicates the charge information. a likely candidate is the
exchange of ghost atom property data.

it is impossible to say more without digging into the code.

is there are particular reason, why you need/want to use fix
property/atom (apart from helping LAMMPS developers to shake out bugs
in the code)?

axel.

4

Dear Axel,

Thanks for your helpful response. Rest assured that we are not trying to cause trouble and we are VERY appreciative of the LAMMPS effort. The fix command method was the one we tried first and we were puzzled that ewald summation misbehaved. (version 28_Jun14) We will be glad to stick with the charge atom_style method since it does seem to be reliable. Thanks again, Natalie

5

Dear Axel,
        Thanks for your helpful response. Rest assured that we are not
trying to cause trouble and we are VERY appreciative of the LAMMPS effort.

no worries. it is actually quite helpful, if people try out new
features carefully. LAMMPS has grown over the last years to such a
level of complexity, that it has become impossible to check out all
permutations of combinations of options and uses of multiple features.
it also leads to situations like this, where even experienced people
overlook what alternatives are possible due to added features.

thus it is highly recommend to do tests just like you did and report
any inconsistencies. many times people come up with uses of features,
that were not anticipated by the developer.

The fix command method was the one we tried first and we were puzzled that
ewald summation misbehaved. (version 28_Jun14) We will be glad to stick
with the charge atom_style method since it does seem to be reliable.

yeah, atom style charge has been around a long time and thus should
work reliably. but we need to put fix property/atom q on the list of
features that need to be corrected, as well.

axel.