On Thu, Oct 19, 2017 at 3:01 PM, A. M.M <alaa.murar@...24...> wrote:
> 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
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.
> 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.
> 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
>> > firstname.lastname@example.org
>> > https://lists.sourceforge.net/lists/listinfo/lammps-users
>> Dr. Axel Kohlmeyer akohlmey@...24... http://goo.gl/1wk0
>> College of Science & Technology, Temple University, Philadelphia PA, USA
>> International Centre for Theoretical Physics, Trieste. Italy.
Dr. Axel Kohlmeyer akohlmey@...24... http://goo.gl/1wk0
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.