LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Mailing List Archives
Re: [lammps-users] Simulation warning
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lammps-users] Simulation warning


From: "A. M.M" <alaa.murar@...24...>
Date: Thu, 19 Oct 2017 22:01:49 +0300


On Thu, Oct 19, 2017 at 9:34 PM, Axel Kohlmeyer <akohlmey@...24...> wrote:
On Thu, Oct 19, 2017 at 1:01 PM, A. M.M <alaa.murar@...24...> wrote:
> بسم الله الرحمن الرحيم
>
> Hello,
>
> I run a simulation for beads-springs polymer(chain) only and I used a pair
> style lj/cut/coul/debye/omp, and I set the cutoff for debye equal to the
> length of the chain plus a distance so the net one is 557.6 angstrom ( I
> used real units ). I used shrink boundary condition for all dimensions, and
> the nsq style for neighbor build, and a 3.0 for skin.
>
> The simulation run well, but the following warning appeared:

i would not expect that simulation to run as well as it could. i would
expect it to run very slow. how large is your simulation cell?

the initial volume was 560.6^3 = 176 million A^3, but during simulation ( shrink bc. ) the volume decrease to a around 1 or 2 million.
contrary to what you said, the simulation runs very quickly. i run 17000000 step with dt = 10.0 fs, and it took around 20 minute on my core i 5 laptop.i have only 24 beads in this chain and no other atoms/beads in the simulation. also my simulation is in implicit solvent(fix langevin + fix nve to perform BD) and ions (through coul/debye pair style).


>
> WARNING: Proc sub-domain size < neighbor skin, could lead to lost atoms
> (../domain.cpp:937)
>
> but no atom was lost. Also, there a few dangerous neighbor builds compared
> to the total one.
>
> Does this warning dangerous? and how can I avoid it ?

your choice of pair style makes not much sense or rather your cutoff
is *massively* oversized and probably your system too small (so you
may be plagued by finite size effects).
you should be running with lj/cut/coul/long and ewald or pppm and a
meaningful cutoff would be in the neighborhood  of 12 \AA.
with a large cutoff you are growing the cost of your computation with
O(r**3) and will have to manage huge neighbor lists and massive
amounts of communication through updating ghost atom data.

also, nsq neighborlist builds are inefficient for larger cells and the
default binning is to be preferred.

axel. 

coul/long pair style does not account the implicitly of ions in my situation. and i used nsq because i faced an error says;
"Cannot use neighbor bins - box size << cutoff"
and in errors page you said below this error:
"Too many neighbor bins will be created. This typically happens when the simulation box is very small in some dimension, compared to the neighbor cutoff. Use the “nsq” style instead of “bin” style." 

Thank you.

>
> Thank you.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> lammps-users mailing list
> lammps-users@...12...396...sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lammps-users
>



--
Dr. Axel Kohlmeyer  akohlmey@...43...4...  http://goo.gl/1wk0
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.