KIM_API_get_sim_species()

4 views
Skip to first unread message

Jakob Schiøtz

unread,
Dec 1, 2018, 3:41:39 PM12/1/18
to OpenKIM Mailing List
Hi Ryan et al. :-)

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

Jakob


--
Jakob Schiøtz, professor, Ph.D.
Department of Physics
Technical University of Denmark
DK-2800 Kongens Lyngby, Denmark
http://www.fysik.dtu.dk/~schiotz/



Ryan S. Elliott

unread,
Dec 1, 2018, 5:47:36 PM12/1/18
to 'Jakob Schiøtz' via openkim
On Sat, 1 Dec 2018, 'Jakob Schiøtz' via openkim wrote:

> Hi Ryan et al. :-)
>
> 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?

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.


Ryan

Jakob Schiøtz

unread,
Dec 2, 2018, 4:04:08 AM12/2/18
to OpenKIM Mailing 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

Jakob
> --
>
> --- You received this message because you are subscribed to the Google Groups "openkim" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openkim+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages