Hi Ryan et al. :slight_smile:

In version 1, a model could discover which elements are present in a simulation using KIM_API_get_num_sim_species() and KIM_API_get_sim_species(). Is it correct that this is not possible in version 2?

I admit that there ought not to be a good reason (aside from optimization) for the model to know this, but there is a weird feature (of the six-legged kind) in the original EMT potential as implemented originally in ARTwork and later in Asap: The cutoff is global, and determined by the largest atom present in the simulation.

This has the most unfortunate consequence that copper changes its properties ever so slightly if there is just a single gold atom present. Asap’s EMT, and the corresponding OpenKIM V1 model handle this by requesting a list of elements from the simulation, and only loading the relevant parameters. But if that is not possible in V2, then all parameters get loaded and the calculator behaves marginally different from the V1 counterpart (but perhaps in a more consistent matter).

One workaround would be to make six parametrized models, with the smallest element, the two smallest elements, etc.

What do you think?

Best regards


Hi Jakob,

Yes, everything you say is correct. We debated exactly this issue when we made the associated design decisions for v2. Ultimately, we opted for the consistency over the optizimation.

One additional thing you could do is to use multiple neighbor list cutoffs. The simulator would still need to generate the large cutoff list, but your model would save time by only using the short cutoff list.


Hi Rya,

Thanks for your quick reply - and that on a Saturday.

The problem is not really one of optimization, as the differences in cutoff is small. It is one of consistency, since the placement of the cutoff has a small effect on energies, forces and materials properties. So in the new API, values will be slightly different since a slightly different cutoff is used (except if gold is present, in which case the large cutoff would also have been used in V1).

I agree with your design choices, and I guess the most correct solution is to give a new KIM model number to the models because of this slight change. And then publish multiple models, as I suggested, but clearly explaining in the README files what is going on.

Best regards