Dear all,
Thank you very much to Ellad, Ryan and Valeriu for a great week. I felt we really got the feel of the OpenKIM interface, and I am sure the project will change the field if it reaches critical mass.
I have a bit of feedback for the API after working with it during last week. It is nothing major, but a few things that would make coding and debugging a little easier.
1.
It would be nice with some kind of way to keep track of which data in the API is valid. So that if the model asks for e.g. numberContributingParticles, and the test has not set it, an error should be produced. Or if that is difficult. then initializing things with "obviously wrong" values likely to cause an immediate failure would also be a possibility. For example NULL for pointers, since dereferencing NULL causes a segfault on most machines, and a large negative value (INT_MIN?) for integers, since that is likely to be a meaningless (and easily detectable) value.
2.
In function declarations, would it be possibly to declare pointer arguments to data that is not modified as const pointers? In particular, the various strings passed to KIM API functions should be 'const char *' instead of 'char *'. That would make it possibly to pass on a pointer that is already const (I had to use a couple of dubious casts to non-const pointers). And it would allow the compiler to do a little bit more error checking and optimization.
3.
The KIM API pointer itself is declared 'void *' in the API, intptr_t * in the examples, and KIM_API_model * in the comments to the api. It would be nice to get rid of the void *, in particular since sometimes it is a pointer to the object, sometimes a pointer to a pointer to the object, and declaring it as void * prevents the compiler from detecting it if we make a mistake.
4.
The model makes its cutoff available when it is initialized, but sometimes that is too pessimistic, and a tighter cutoff could be used for a specific system. In particular, if a model treats a large number of elements, the cutoff may vary according to which elements are present. In EMT, the cutoff for Au is 15% longer than the cutoff for Ni, but since the model does not know which elements are present when publishing its cutoff, neighbor lists etc in a pure Ni simulation will have a cutoff that is 15% longer than necessary, and the neighbor list will thus be 50% longer optimal, at some performance penalty.
It is not obvious how to address this. Clearly, the model cannot adjust the cutoff after the first calculation based on what it sees then. The system may have changed before the next calculation (either due to "alchemy" in a Monte Carlo simulation, or due to migration of atoms in a parallel simulation where all atoms of one kind started in a limited region of space).
Could there be some optional way a simulator/test could inform the model about the elements actually being used before the first calculation? KIM_API_announce_list_of_types(pkim, ntypes, type_ptr)? It should be optional in the way that no model should count on getting this information, the model can at most optimize itself and change the published cutoff (and other parameters?) accordingly IF the test chooses to call it. And it should not be an error to call this function even if the model does not support it. But is should be an error to call the function, and then later break the promise about which elements are at most present.
Anyway, as you can see I have no major issues with the KIM API, only a few comments. I think the present API is well thought through, and likely to cover most situations. Good luck with the project, I am looking forward to be a (small) part of it.
Best regards
Jakob