So, as you know, I agree that we need to transition to a scheme that separates
the identification of padding particles from the neighbor list information.
However, within the current system, I think the problem has a solution (unless
I misunderstand):
I know a plan is in the works, but I’m finding this discussion to be very
enlightening, and I think it’s certainly revealing to me some aspects of
any proposed improved scheme that I didn’t appreciate before.
You say that Models, such as the ones mentioned above, need the neighbors of
padding particles in order to correctly compute the energy (and by
differentiation the forces).
Based on this statement, I believe that the problem is that the Model’s cutoff
radius is being incorrectly specified. If the energy of particle i depends on
its neighbors j (r^{ij} < r_1) AND in order to complete the calculation you
also need to know the neighbors of j: k (r^{jk} < r_1), then in fact, the
actual Model cutoff (as defined by the KIM API) is r_2 = 2*r_1.
With this specification of the Model cutoff, a domain-decomposition scheme will
ensure that all padding j (neighbors of i) particles will have enough
surrounding padding particles k (neighbors of j) to ensure that j has all its
neighbors.
So this is where I just realized one thing I hadn’t realized before.
Really, the way KIM does neighbors, there are two cutoffs. There is one
cutoff for the neighbor list itself, and another cutoff for the ghost atoms.
The first is needed for direct interactions, i.e. things that have to be explicitly
looped over (I’ll call these immediate neighbors), e.g. atoms within
the interaction cutoff for LJ or Stillinger-Weber, or accumulating atomic bond
orders for REBO-type potentials. The new (to me) thing is that for
ghost atoms there’s a distinct and potentially larger cutoff, which includes
indirect interactions like neighbors of neighbors, where you need neighbors
of ghost atoms to calculate information about the ghost atoms, but you don’t
directly need to loop over an atom and its non-immediate neighbors. I’ll
call these extended neighbors.
Obviously you can always specify the larger cutoff and then, in the loops
that require only immediate neighbors skip atoms that are too far. But this
will increase computing time (perhaps trivially) and increase the memory
demands of the neighbor lists. For pair-type interactions the extended
cutoff is double the immediate cutoff, and then 7/8 of the neighbors (in 3D)
are too far. For dihedrals you need 3rd neighbors, and if you multiply
your cutoff by 3, 26/27 of the neighbors are too far.
Now, it is true that the neighbor list for particle j will be empty. However,
the neighbor list for particle i will contain j and all of its neighbors. So,
although it will be somewhat inefficient, it is straight forward to find the
neighbors of j. Just loop over the neighbors of i (with index k) and test the
relative position vector between j and k.
So I’ve been thinking about whether I can implement this for QUIP, and I
think I agree that it’s possible, but it’s not as simple as you make it sound.
In particular, the extended neighbor list for particle i is not guaranteed to
include all the immediate neighbors of particle j. I think it is true that the
union of all extended neighbor lists of all particles {i} that have j as a neighbor
includes all the neighbors {k} of particle j, but any one of them is not
guaranteed to do so.
For the benefit of anyone else who needs to deal with this in the future,
I’ve attached a picture to show the problem. j should have k and k’ as its
immediate neighbors. However, k is only in the extended neighbor list of i,
and k’ is only in the extended neighbor list of i’. So you have to create the
immediate neighbor list of j from the union of the extended neighbor lists
of i and i’. A further problem is illustrated by j and k’’. They are both in
the extended neighbor lists of both i and i’, which means that a naive
algorithm will add the j-k’’ neighbor relation twice. You therefore have to
check for duplicate neighbors, which in the case of rvec and the possibility
of multiple images means you have to search through the list of neighbors
of j and test the identity and the relative vector of any neighbor to make
sure it hasn’t already been added. I think I can do this for QUIP, but
it won’t be efficient. Probably won’t matter for GAP, but for a cheaper
potential, it could be an issue.
Noam
neighbor_of_ghost.pdf (6.96 KB)