Multiple KIM model instances in simulator?

For HPC can multiple model instances be “spawned” or can the KIM model be used as a library, i.e. 10 threads computing 10 different force calculations from 10 separate KIM models?

Yes, a KIM Model is essentially a library of functions which take as input atomic positions, species etc., and render as output forces, energy, etc. Accordingly, there really isn’t any limitation to how you can use the Model.

Dan

Great, thanks!

In an attempt to be more complete, we should discuss thread safety of the various pieces of code.

Tests/simulators interact with models through a “KIM object,” which is a data structure encapsulating all the data needing to be passed between tests/simulators and models. Objects are as thread safe as your test or simulator makes them.

Models are intended to be thread safe, but there is presently no guarantee of such. There are ongoing discussions about putting validators in place to test the thread safety of uploaded models, inasmuch as such a thing can be tested.

It’s certainly possible to do what you want, in which case each thread might have its own private KIM object, with each one using (possibly) different models. I’ve done this, with each object using the same model, and it worked for me.

Steve

Steve,

Thanks for your comments. Very nice.

It's certainly possible to do what you want, in which case each thread might have its own private KIM object, with each one using (possibly) different models. I've done this, with each object using the same model, and it worked for me.

A serial example using 4 KIM API interface objects with 2 different Models is shipped with the KIM API examples. It is ex_test_Ar_multiple_models. This example also shows how a Simulator can actively manage the memory pointed to by a KIM API object instead of using the KIM_API_allocate() routine.

In this case the Simulator avoids multiple copies of an identical coordinates array and has two of the KIM API Interface objects point to the same memory location. (So, I suppose that could cause problems with thread saftey...)

Cheers,

Ryan

Steve: Thank you for the extra details, that is exactly what I was imagining doing.

Ryan: Thanks for the reference to the example. I will take a look at it before the KCC event on Monday and think about how I want to handle thread safety.

Both: How computationally expensive is it to instantiate a KIM Model object? Is there a lot of memory overhead with KIM Model object independent of the number of atoms? I know these might be strange questions, but the simulator I am planning on implementing KIM in at the KCC has some trickiness to it. I am currently seeing two routes to implementation for the simulator.

  1. Instantiating potentially 100000s of models and updating the atom locations lists on the order of millions of times.

  2. Instantiating and then destroying models on the fly on the order of millions of time.

Method 1 saves me the computational expense of re-initialization of non atoms list data, but costs me memory. Method 2 reduces memory footprint, but requires a potentially higher computational expense with instantiation of KIM Models. I was hoping to get a feel for the relative memory and computational expenses, which might influence the method I implement.

If these questions are better addressed in person, we could talk at the KCC if either of you are there, pending your time availability.

Thanks,

Jason

Jason,

These are very interesting questions....

Both: How computationally expensive is it to instantiate a KIM Model
object?

Not very (relative to a typical energy/force calculation). But I can't say much in detail. It would be very interesting to perform a study of this in order to quantify it more precisely.

Also, of note, the KIM_API_model_init() portion of the initialization can represent a significant computational overhead for some Models. For example, this can include reading in parameter files (which can be very large for some models), processing these parameters and storing the internal data structures that the Model uses.

Is there a lot of memory overhead with KIM Model object
independent of the number of atoms?

The API itself should have a low memory overhead. However, each Model can introduce its own memory needs. So, the total answer here is that it depends on the Model. Some models will have significant memory overhead.

I know these might be strange questions, but the simulator I am planning on implementing KIM in at the KCC has some trickiness to it. I am currently seeing two routes to implementation for the simulator.

1) Instantiating potentially 100000s of models and updating the atom
locations lists on the order of millions of times.
2) Instantiating and then destroying models on the fly on the order of
millions of time.

Method 1 saves me the computational expense of re-initialization of non
atoms list data, but costs me memory. Method 2 reduces memory footprint,
but requires a potentially higher computational expense with instantiation
of KIM Models. I was hoping to get a feel for the relative memory and
computational expenses, which might influence the method I implement.

If these questions are better addressed in person, we could talk at the KCC
if either of you are there, pending your time availability.

There are definite trade-offs here. I think probably some experimentation will be necessary to determine the best solution...

There may be other possibilities too. For example, using just one KIM API Interface object for each model and "swapping out" the memory pointers corresponding to different configurations before each energy/force call...

This will be a fun discussion to have and explore!

Ryan,

Thanks for the information and thoughts. The other option you mentioned
definitely could work as well. I didn't know if I could just swap in the
new configuration (with different number of atoms, species, neighborlists)
without going through an initialization process again. I will continue
looking through the KIM documentation and examples, especially the
different data structure dependencies, for Monday. I am looking forward to
the discussion, it should be both interesting and informative for me.

Thanks,

Jason