-------- Original message --------
From: Mohammad Rafat Sadat <msadat@...3324...>
Date: 6/19/2017 06:54 (GMT-05:00)
To: ss3763 <ss3763@...1685...>
Cc: Jana Pritam <pritam.jana@...3660...>, LAMMPS Users Mailing List <firstname.lastname@example.org>
Subject: Re: [lammps-users] out of range atoms - cannot compute PPPM
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 PPPMOne 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 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 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."