Simulation warning

بسم الله الرحمن الرحيم

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:

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 ?

Thank you.

بسم الله الرحمن الرحيم

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?

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.

> بسم الله الرحمن الرحيم
>
> 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.

> بسم الله الرحمن الرحيم
>
> 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

that is because i was assuming, that you have set up a meaningful simulation.

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).

to run a single 24 bead chain in such a system is equally pointless.

if you do implicit solvent, there is no reason to run a variable cell.

any cutoff that is longer than the maximum extent of the chain from
end-to-end is sufficient for such a system unless you have multiple
chains. similarly, there is no reason to have periodic boundaries.

>
> 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

do you follow a specific paper that provides you with the settings or
do you decide on them yourself?

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."

yes, but that is because your system settings are unreasonable.

axel.

>
>>
>> > بسم الله الرحمن الرحيم
>> >
>> > 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

that is because i was assuming, that you have set up a meaningful
simulation.

i am sorry, i am a beginner.

> 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).

to run a single 24 bead chain in such a system is equally pointless.

if you do implicit solvent, there is no reason to run a variable cell.

any cutoff that is longer than the maximum extent of the chain from

end-to-end is sufficient for such a system unless you have multiple
chains. similarly, there is no reason to have periodic boundaries.

thanks a lot for your advice.

>
>>
>> >
>> > 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

do you follow a specific paper that provides you with the settings or
do you decide on them yourself?

there is an article using coul/debye for electrostatic interactions in
implicit solvent and ions system, from this article i guessed that pure
coulomb potential must not used when implicit ions are placed.

> 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."

yes, but that is because your system settings are unreasonable.

again i am sorry for meaningless situation or simulation.

Thank you.