Hi Steve,
Thanks for your response. See below.
(1) kim-api-v2 requires full neighbor lists with all neighbors:
local-local
local-ghost
ghost-local
ghost-ghost
Does this mean all KIM potentials require all of this info,
or some will want it?
It seems overkill for many potentials.
Yes, all KIM potentials will require this type of neighbor list.
For simplicity, we decided that only this sort of neighbor list would be supported in kim-api-v2. We believe that the overhead incurred by this choice is minimal, except maybe for very simple potentials. The worst case, I think, is something like LJ where this overhead consists of:
(1) Extra time to generate the full-list with all l-l, l-g, g-l, g-g neighbors; as opposed to the minimal necessary half-list with only l-l, l-g neighbors. Since the neighbor list is only updated periodically, this overhead is amortized across multiple compute() calls.
(2) Extra time in the main LJ loops, but this can be mitigated to an extent by making the loops look like (in pseudo code):
for (i=0, i < n_local, ++i) {
for (jj=0, jj< n_neigh_i; ++jj) {
j = neigh_i[jj];
if (i < j) {
phi += energy contrib. of i,j pair
atom->f[i][:] += force contrib. of i,j pair
atom->f[j][:] -= force contrib. of i,j pair
}
}
}
Does this have an impact on how/if pair_kim supports the "newton" option?
As Axel said, a full neighbor list has all pairs twice, so you have
all the info you need to compute whatever you wish inside KIM.
However, the forces you return are handled differently by LAMMPS depending
on newton on vs off. If "on", then LAMMPS will assume there are
forces on ghost atoms and do 2 things: reverse comm to sum ghost
forces to owned-atom forces. And do a cheaper virial computation
which uses the ghost forces (doesn't need to worry about periodic BC).
If "off" then LAMMPS will assume each owned atom already
has its total force and do no comm.
So whatever KIM computes for forces would need to match that.
If KIM will always return total force on each owned atoms
(and 0.0 on the ghost atoms), then the extra comm for newton on
will not hurt I guess.
OK, thanks for the clarification. We had already grappled with this in the existing pair_kim code and the way forces are computed has not changed in kim-api-v2. So, I think I've preserved working behavior for the forces...
Any further comments/suggestions are always welcome.
Thanks,
Ryan