Boundary condition and parallel decompostion

Hi all,

I have several questions about the boundary condition and how LAMMPS decomposes the simulation box to a 3D grid of processors depending on the boundary condition.

1, If I want to simulate a free polymer chain for a very long time, at the end of the simulation, the polymer may diffuse a long distance from its original place, but I don’t want the wall interacts with polymer, and I also don’t want the polymer interacts with its image if I use a periodic boundary condition since I am simulating a free polymer. In this situation, what kind of boundary condition do I need to achieve a good balanced computing performance on all processors I am going to use?

2 In this situation, if I use a big box (to ensure the polymer will never touch the border ) with the f (non-periodic and fixed ) boundary, according to the manual this will not give a good distribution of the computing load for a 3D grid processors, but if I use a big box with the periodic boundary condition, how does LAMMPS distribute the computing load among the processors?

3 In this situation, if I use a small box ( which just encompasses the polymer ) with s (non-periodic and shrink-wrapped) as the boundary condition, will the wall of the box will dynamically change along with the moving the polymer?

4 In any boundary condition being used, p or f or s or m, I don’t think there is any interaction from the wall, am I right?

Thanks in advance!!!

Allan Huang

You should use s s s boundary condition. This will give you the
correct behavior. As for performance, that will depend a lot on the
structure of the polymer and how many processors you are using.
LAMMPS has some features that will help. Read the doc pages for the
commands processors, balance and fix balance, and then do some
experiments.

This sounds like a very inhomogeneous sparse system.

I am using LAMMPS for this kind of simulation as well (an extremely
long dilute polymer in either a vacuum or in a good implicit solvent).
What I found so far:

Take a look at "neighbor nsq"
http://lammps.sandia.gov/doc/neighbor.html
"For unsolvated small molecules in a non-periodic box, the nsq choice
can sometimes be faster. Either style should give the same answers."

Trung mentioned that "force decomposition" is available in LAMMPS if
you compile it with the optional USER-OMP package. (I assume this is
the algorithm described on page 3 of this paper
http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf)

I will try out these options in the next few days and report what I find.
Other suggestions welcome.

Cheers!
Andrew

[...]

Trung mentioned that "force decomposition" is available in LAMMPS if
you compile it with the optional USER-OMP package. (I assume this is
the algorithm described on page 3 of this paper
http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf)

not really.

when you use multi-threading (through OpenMP or otherwise), you don't
need to communicate position data between tasks (threads in this
case), since you are sharing memory between them (the tricky part is
to accumulate the forces later without "losing" some contributions).
the multi-threaded kernels use a simple work distribution scheme,
where each thread/task processes the same number of atoms. this can
also lead to load-balancing issues, but they are not couple to the
volume of the total box or individual domains.

and since the currently available load-balancing in LAMMPS works
better with larger subdomains, there can be a benefit from using
(some) threads over MPI inside a multi-CPU/multi-core node.

axel.