I have a question regarding the KIM_API_get_neigh function. The documentation states that the last argument (double** rij) is set to NULL except when using the NBC method NEIGH_RVEC_F. In my code I rely on that to test if the rij array is available. This doesn't work when using the KIM pair_style in LAMMPS (version 4 Dec 2012). LAMMPS returns a pointer to some address although it uses NEIGH_PURE_F. The array is filled with zeros in my case (probably uninitialized memory?).
The KIM API is version 1.1.1.
Is this a bug in KIM or LAMMPS, or should we not rely on rij being NULL?
Thanks for your question. Technically, this is a bug in the pair_kim implementation in LAMMPS. The code should set this pointer to NULL when not using NEIGH_RVEC_F. I'll make a note of it and get a fix into the next release.
However, I should mention that the method you describe is not the perferred approach to determining the NBC method agreeded upon during the KIM Model/Test matching process. It would be best to use the
KIM_API_get_NBC_method()
call defined by the API. If the value is anything other than NEIGH_RVEC_F, then the rij array is not available (or at least may not be reliable).
You're right that one should use the KIM_API_get_NBC() function and I do that. What I'm doing is using a wrapper compute function which calls all the KIM API functions like get_NBC_method etc. and passes a bunch of flags (like use neighbor list or not etc.) to another function which actually does the computation. The reason is that the computation function is ported from legacy code to the KIM API and I wanted to keep as many KIM specific functions out of it as possible.
I didn't pass a flag that differentiates NEIGH_PURE_F and NEIGH_RVEC_F, though, and relied on the rij array being NULL for NEIGH_PURE_F. I guess I will change that at least for the benefit of users of older LAMMPS versions.