Dear All,
Imagine some not really effective situation when
one has a really small simulation cubic box periodic in all three directions (side of the cube is around 22 Angstroem).
The force cutoff radius is 10 Angstroem.
And then to simulate such a system we use a large number of processors say n=20. So the overall initial system will be split up into many sub-domain of the size much smaller than the cutoff radius. (The potential is very difficult to calculate numerically this is why I need a large number of processor to speed up the calculation).
My question is the following:
When the neighbour list for a given domain is constructed in LAMMPS, will it include the information about the neighbour s from all the neighbouring domains withing the cutoff around this given domain or will it include only those neighbour atoms which are located only in the nearest neighbour domains which have an immediate direct border with this given domain?
Thank you in advance!
Dear All,
Imagine some not really effective situation when
one has a really small simulation cubic box periodic in all three directions
(side of the cube is around 22 Angstroem).
The force cutoff radius is 10 Angstroem.
And then to simulate such a system we use a large number of processors say
n=20. So the overall initial system will be split up into many sub-domain of
the size much smaller than the cutoff radius. (The potential is very
difficult to calculate numerically this is why I need a large number of
processor to speed up the calculation).
My question is the following:
When the neighbour list for a given domain is constructed in LAMMPS, will it
include the information about the neighbour s from all the neighbouring
domains withing the cutoff around this given domain or will it include only
those neighbour atoms which are located only in the nearest neighbour
domains which have an immediate direct border with this given domain?
you can make a very simple test for that:
boundary p p p
region box block 0 1 0 1 0 1
neighbor 0.01 nsq
create_box 1 box
create_atoms 1 single 0.5 0.5 0.5
mass 1 1.0
pair_style lj/cut 0.2
pair_coeff * * 0.0 0.1
run 0
pair_style lj/cut 1.0
pair_coeff * * 0.0 0.1
run 0
pair_style lj/cut 2.0
pair_coeff * * 0.0 0.1
run 0
looking at the neighborlist statistics after each run you should see
that in the first case you have 1 local atom and no ghosts, in the
second case 1 local and 26 ghosts (3x3x3) and in the third case 1
local and 124 ghosts (5x5x5).
so, yes, you can parallelize this correctly. however, the more CPUs
you're trying to use, the works the ratio of volume to surface gets
and thus the lower your parallel efficiency. particularly for
computationally demanding pair styles, it is therefore usually more
efficient to use multi-threading. and efficiency will go up with the
number of CPU cores you want to use.
axel.