out of range atoms - cannot compute PPPM

Increasing the neighbour skin distance is not the solution.

Please refer to the archives both of you.


I beg to differ on that. It may not be the only solution but it is a solution which worked for me on several occasions (used neighbor 3.0 bin instead of 1.0, correct me if this is a wrong thing to do) . If you increase the skin distance then the atoms will have less probability to move out of the processor sub domain and getting ‘lost’. However, too much increase in skin distance may not be a good idea. Possibility of bad geometry, forcefield parameters, too large timesteps shouldn’t be neglected as well. I believe there are other solutions listed in the past. Section error page clearly outlines this problem:

"Out of range atoms - cannot compute PPPM

One or more atoms are attempting to map their charge to a PPPM grid point that is not owned by a processor. This is likely for one of two reasons, both of them bad. First, it may mean that an atom near the boundary of a processor’s sub-domain has moved more than 1/2 the [*neighbor skin distance*](http://lammps.sandia.gov/doc/neighbor.html) without neighbor lists being rebuilt and atoms being migrated to new processors. This also means you may be missing pairwise interactions that need to be computed. The solution is to change the re-neighboring criteria via the [*neigh_modify*](http://lammps.sandia.gov/doc/neigh_modify.html) command. The safest settings are “delay 0 every 1 check yes”. Second, it may mean that an atom has moved far outside a processor’s sub-domain or even the entire simulation box. This indicates bad physics, e.g. due to highly overlapping atoms, too large a timestep, etc."
1 Like

I beg to differ on that. It may not be the only solution but it is a
solution which worked for me on several occasions (used neighbor 3.0 bin
instead of 1.0, correct me if this is a wrong thing to do) .

increasing the neighborlist skin ​sounds like workaround ​that avoids the
symptom, but may not solve the problem. what you need to understand is,
*why* atoms move so fast, that they move too large a distance between time
steps. for that it is crucial to know, whether this only happens at the
beginning of a run or also during a run. absolute values for run parameters
are not a good handle to differentiate between "good" and "bad", as what is
a good choice is determined by the system itself, its potentials,
constituent elements, simulation parameters (time integration fix, time
step, temperature, pressure etc.) and more.

in general, it is often a bad idea to start a simulation immediately with
fix npT. the nose-hoover thermostat and barostat algorithms are good for
maintaining the desired ensemble, but are often ill suited to get you there
(efficiently). as arun hinted at, i have discussed this in great detail
multiple times in the past, and you should be able to find those e-mails in
the mailing list archives.


Dear all,
I tried to overcome this problem by changing timestep, check the initial configuration, neighbour skin and previous suggestions from Axel. What I understood from the video of the equilibration, during the NPT simulations when the box squeezed and equivalent to the length of water molecules, the error appears. When I was running NVT, there is no such problem. Could you please make some comment which other things I should check? I add here input script.

newton on
variable T equal 298.0
variable T1 equal 360.0
variable DT equal 0.25
timestep {DT} thermo 1 units real atom_style full dimension 3 boundary p p p kspace_style pppm 1.0e-4 include system_water.in.init read_data system_water.data include system_water.in.settings group spce type 1 2 neighbor 3.0 bin neigh_modify every 1 delay 1 check yes velocity all create {T1} 19289 mom yes rot yes dist gaussian
unfix fShakeSPCE
minimize 1.0e-4 1.0e-4 10000 100000
fix fShakeSPCE all shake 0.0001 20 0 b 1 a 1
fix NVT all nvt temp {T1} {T1} 100.0
dump dump_NVT all atom 10 all_NVT.dump
run 1000
fix NVT all nvt temp ${T1} $T 100.0
run 1000
unfix NVT
fix NPT all npt temp $T $T 100.0 iso 1.0 1.0 100.0
run 50000