pair_peri_pmb loop efficiency

Hello Users,

I’m looking over the pair_peri_pmb.cpp source and in the compute function (line 77) there are two nested for loops, line 122 and line 199.

The nested loop at line 122 is to calculate short range forces and the loop starting at line 199 calculates the PMB forces. I’m trying to figure out why these are two separate loops? Why are these two nested loops not combined for efficiency?

My confusion my stem from not understanding the difference between the list that are being looped over:

first nested loop uses: “inum = list->inum”

second nested loop uses: “nlocal = atom->nlocal”

If it is possible to join these two nested loops, I would imagine a decent speed up.

Thanks for the input.

Hello Users,

I'm looking over the pair_peri_pmb.cpp source and in the compute function
(line 77) there are two nested for loops, line 122 and line 199.

The nested loop at line 122 is to calculate short range forces and the loop
starting at line 199 calculates the PMB forces. I'm trying to figure out
why these are two separate loops? Why are these two nested loops not
combined for efficiency?

because they loop over different atoms.

axel.

Why are they looping over different atoms? Both loops should be looping over the atoms within an atom’s horizon.
What is the difference in:

inum = list->inum
nlocal = atom->nlocal

I believe nlocal is the atom’s neighbors?

Thanks

Why are they looping over different atoms? Both loops should be looping over
the atoms within an atom's horizon.
What is the difference in:

inum = list->inum
nlocal = atom->nlocal

I believe nlocal is the atom's neighbors?

no it is not. not at all.

nlocal is the number of owned atoms, i.e. atoms that "belong" to the subdomain.
inum, is the number of entries in the neighbor list. it can be the
same, but it need not be the same.

however, this is not the factor that matters the most. this only
selects the outer loop indices.
where there is a major difference is the inner loop. the first is over
the (current) neighbors, the second over the "partner" list which is,
if i remember correctly, a curated list of neighbors at the beginning
of the simulation. these neighbors are unchanged and migrate with the
outer atoms between subdomains.

i suggest you try to not so eagerly jump to conclusions, especially
when you are surveying the code in a rather superficial way and
without test inputs documenting the issue. while we already have
established, that there are some unexpected choices in the
peridynamics code, as far as i can tell, they all seem to be rooted in
the assumption, that there is only one type of atom in a simulation.
that is very different from what you are currently asking about.

there are indeed some ways to speed up calculations through code
optimization, but they are in neighborhood of 5-10% improvement.
several of those are implemented in the USER-OMP package variant of
the respective pair style.

axel.