>> > بسم الله الرحمن الرحيم
>> > 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
>> > length of the chain plus a distance so the net one is 557.6 angstrom
>> > used real units ). I used shrink boundary condition for all
>> > 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
that is because i was assuming, that you have set up a meaningful
i am sorry, i am a beginner.
> step with dt = 10.0 fs, and it took around 20 minute on my core i 5
> have only 24 beads in this chain and no other atoms/beads in the
> also my simulation is in implicit solvent(fix langevin + fix nve to
> 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
>> > (../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.
> 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.