ewald vs pppm

LAMMPS LAMMPS Mailing List Mirror
1

I’m using ewald in my simulations by specifying:

kspace_style ewald 0.0001

After reading that pppm is Nlog(N) I substituted the following:

kspace_style pppm 0.0001

and the following message was generated. I did not received this message with the ewald run.

Does this occur due to the system I am simulating? or do I need a smaller precision value?

Thanks in advance,

-Bruce

ERROR on proc 7: Out of range atoms - cannot compute PPPM (pppm.cpp:1490)
[Profmembrane.local:07856] MPI_ABORT invoked on rank 7 in communicator MPI_COMM_WORLD with errorcode 1
mpiexec noticed that job rank 0 with PID 7849 on node Profmembrane.local exited on signal 15 (Terminated).
6 additional processes aborted (not shown)

<<<< LAMMPS SCRIPT >>>>

Epoxy Know Original Recipe with longer equilibration times at hot temperature

and MM minimization every round

units real
atom_style full

#package gpu force 0 0 -1
#newton off

#pair_style lj/class2/coul/long/gpu 9.5 10.0
pair_style lj/class2/coul/long 9.5 10.0
bond_style class2
angle_style class2
dihedral_style class2
improper_style class2

#kspace_style pppm 0.0001

kspace_style ewald 0.0001
kspace_modify order 6

read_data dgeba_ipd_cff91.lammps05
#read_data dgebaipd5x20.lammps05

timestep 1.0

neighbor 4.0 bin
neigh_modify every 1 delay 0 check yes page 1000000 one 100000

#compute peratom all stress/atom virial
#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)

#compute mypress all pressure thermo_temp
#compute p all reduce sum c_mypress[1] c_mypress[2] c_mypress[3] c_mypress[4] c_mypress[5] c_mypress[6]
#variable press equal mypress

thermo_style custom step pe ke etotal lx ly lz temp press

thermo 2000

#Minimize the system using LAMMPS

dump 1 all atom 10 dgebasipd_min_fire_quad-3.lammpstrj

min_style cg
min_modify line quadratic
fix 1 all box/relax aniso 1.0 vmax 0.001
minimize 0 0 10000000 10000000
unfix 1

min_style fire
min_modify line quadratic

minimize 0.000000000001 0.000000000001 10000 10000

write_restart dgebaipd_min_fire_quad-4.%.*

#undump 1

#dump 1 all atom 20 sxyz_quench.lammpstrj

Was using Tg - 40 now using 298.0

#fix 1 all temp/rescale 1 298.0 298.0 2.0 1.0
#fix 2 all nve

fix 1 all nvt temp 298.0 298.0 100.0

timestep 0.001

run 10000

timestep 0.01

run 10000

timestep 0.1

run 10000

timestep 1.0

run 10000

unfix 1
#unfix 2

Checkpoint the calculations for restart

write_restart sxyz_quench.%.*

2

Bruce,

Looks like atoms are being lost. Usually this means that forces on atoms are too large due to either atom overlaps or incorrect calculation of the forces. Since “kspace_style ewald 0.0001” seems to be working for you, your configuration is probably OK. I’d recommend trying a smaller (better) precision value to see if that works better, at least during initialization.

Note that the kspace accuracy (“precision”) is only an estimate. Results may vary.

Also note that this part of LAMMPS (how the accuracy is estimated) has recently changed (March 2nd version of LAMMPS), particularly for Ewald. See: http://lammps.sandia.gov/bug.html I can’t tell which version you’re using.

Paul

3

What's more likely is that your dynamics is bad
for both PPPM and Ewald, but only PPPM is
complaining about it. That's b/c it requires that
atoms don't move so far that their charge can't
be mapped to a processor's grid points. Ewald
effectively stores all grid points on all processors,
which is why it's slow.

The usual fix for this (see Section_errors.html) is
to insure you are reneighboring often enough
(delay = 0, every = 1, check = 1) that atoms
don't move too far.

Steve