Increasing the neighbour skin distance is not the solution.
Please refer to the archives both of you.
Arun
Increasing the neighbour skin distance is not the solution.
Please refer to the archives both of you.
Arun
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
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.
axel.
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
clear
Best
Pritam