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)