Soon to release Asap simulator - but I have some questions.

Dear OpenKIM folks,

I am soon going to release a new version of my simulation software Asap, this time with full OpenKIM support. Asap is a calculator for the Atomic Simulation Environment (ASE) with a special focus on large-scale molecular dynamics on parallel computers (clusters).

In that connection, I have some questions regarding a few loose ends:

1) How can I control from where the KIM API loads the models. Currently, the Asap makefile finds the KIM header files and libraries in the kim-api directory, and the KIM library then loads the model from kim-api/src/models. But if Asap is installed on a cluster, it would need to be able to load models from several directories. Presumably, we will install a directory with pre-compiled KIM models, but the user should also be able to download/write his own, and have them loaded. Is there a function call or an environment variable I can use to control this? I guess this should be documented as part of the KIM API, even if it is an environment variable or something similar.

2) Is there a way a simulator can *read* the KIM search path? This is much less important, but the simulator might use this to list the directories, and build a drop-down menu of possible models in a GUI.

3) Is it safe to load more than one model into the same running process? Since ASE/Asap is mainly used as Python modules, a user might decide to use two or more models in the same script. Is there a risk that this cause namespace collisions, if e.g. both models contain a function named “compute”, or does the KIM library isolate models from each other? Does KIM_API_model_info() also load the module, or does it inspect it without loading it?

4) Is there a way to download all KIM Models compatible with the current API? Or to download all models (then I can sort them myself)? Or to get a list of all models, so I can script the download?

5) What is the official name of the project. It used to be OpenKIM, but is it KIM now? Or are KIM and OpenKIM subtly different?

That was a lot of questions. I hope to pay back with a Simulator. :slight_smile:

Best regards

Jakob

Hi Jakob,

This is great news! We're excited about adding Asap to the list of fully KIM-Compliant Simulators.

See below for answers to (or at least comments on) your questions.

Dear OpenKIM folks,

I am soon going to release a new version of my simulation software Asap, this time with full OpenKIM support. Asap is a calculator for the Atomic Simulation Environment (ASE) with a special focus on large-scale molecular dynamics on parallel computers (clusters).

In that connection, I have some questions regarding a few loose ends:

1) How can I control from where the KIM API loads the models. Currently, the Asap makefile finds the KIM header files and libraries in the kim-api directory, and the KIM library then loads the model from kim-api/src/models. But if Asap is installed on a cluster, it would need to be able to load models from several directories. Presumably, we will install a directory with pre-compiled KIM models, but the user should also be able to download/write his own, and have them loaded. Is there a function call or an environment variable I can use to control this? I guess this should be documented as part of the KIM API, even if it is an environment variable or something similar.

The primary resource for this is the INSTALL file in the kim-api package.

It sounds like you have been linking Asap with an "in place" build of the KIM API for your development.

The recommended approach is to link with an "installed" build of the KIM API. (In the future, we hope near future, we plan to have the KIM API available as a package for your favorite system package manager [brew, dpg, rpm, ect.]).

As described in steps 5--8 of the INSTALL file once installed, the KIM API will look in three places for Models and Drivers. First, it looks in the current working directory. Second it looks in the "User directories"; These are specified by a configuration file in the user's home directory (e.g., ${HOME}/.kim-api/config-v1). Finally, it looks in the "System directories" where Models and Drivers can be made available to all users of the system.

This scheme is quite flexible. However, I am continuing to consider generalizations/modifications/extensions to the scheme. Including the possibility of adding special environment variables that could override the standard values for the various paths. Thus, comments and suggestions are welcome.

2) Is there a way a simulator can *read* the KIM search path? This is much less important, but the simulator might use this to list the directories, and build a drop-down menu of possible models in a GUI.

Currently, NO. However, I agree that this is a desirable function. I would think that a routine that effectively provides the list of all currently available Model names would be the way to go... What do you think? This is somewhat different than what you ask for, but achieves the same thing in this example, at least.

3) Is it safe to load more than one model into the same running process? Since ASE/Asap is mainly used as Python modules, a user might decide to use two or more models in the same script. Is there a risk that this cause namespace collisions, if e.g. both models contain a function named “compute”, or does the KIM library isolate models from each other?

YES. Assuming the Model/Driver fully conform to the API specification, it is safe to use multiple instances of any combination of models. For example, you can create 15 KIM API objects (via any combination of calls to KIM_API_file_init() or KIM_API_string_init()) with 5 associated with Model A, 6 associated with Model B, and 4 associated with Model C. (Further, Model B and C, could both be based on the same Model Driver D.)

Since the KIM API uses dynamically loaded libraries (.so's) and explicitly uses version-scripts to hide all symbols in these libraries execpt for those exclusively under the control of the KIM API, there should be no danger of symbol collisions.

Does KIM_API_model_info() also load the module, or does it inspect it without loading it?

This function loads, extracts data, then unloads the dynamic library associated with the requested Model.

4) Is there a way to download all KIM Models compatible with the current API? Or to download all models (then I can sort them myself)? Or to get a list of all models, so I can script the download?

This is effectively on our TO-DO list; So, currently there is not an easy way of obtaining this list.

However, you could use our query interface to get the sort of information you are looking for:

To see the information associated with each model you can do something like this:

curl -d 'fields={}' -d 'database=obj' -d 'limit=1' -d 'flat=on' -d 'query={"type":"mo"}' https://query.openkim.org/api

To get a list of all Models in the system you can do:

curl -d 'fields={"kimcode":1}' -d 'database=obj' -d 'query={"type":"mo"}' https://query.openkim.org/api

5) What is the official name of the project. It used to be OpenKIM, but is it KIM now? Or are KIM and OpenKIM subtly different?

Take a look here:

https://openkim.org/brand/

Cheers,

Ryan

Hi Jakob,

This is great news! We're excited about adding Asap to the list of fully KIM-Compliant Simulators.

I must be honest and say that “soon” does not mean this week :slight_smile: I have a couple of other tasks that I have to give higher priority. But a release in November or December should be realistic.

1) How can I control from where the KIM API loads the models.

   [ … ]

This scheme is quite flexible. However, I am continuing to consider generalizations/modifications/extensions to the scheme. Including the possibility of adding special environment variables that could override the standard values for the various paths. Thus, comments and suggestions are welcome.

This is indeed quite flexible, and I do not think that anything beyond this is necessary.

2) Is there a way a simulator can *read* the KIM search path? This is much less important, but the simulator might use this to list the directories, and build a drop-down menu of possible models in a GUI.

Currently, NO. However, I agree that this is a desirable function. I would think that a routine that effectively provides the list of all currently available Model names would be the way to go... What do you think? This is somewhat different than what you ask for, but achieves the same thing in this example, at least.

Your suggestion is better. It should preferably also test for compatibility with the current KIM API version number.

3) Is it safe to load more than one model into the same running process?

YES. Assuming the Model/Driver fully conform to the API specification, it is safe to use multiple instances of any combination of models. For example, you can create 15 KIM API objects (via any combination of calls to KIM_API_file_init() or KIM_API_string_init()) with 5 associated with Model A, 6 associated with Model B, and 4 associated with Model C. (Further, Model B and C, could both be based on the same Model Driver D.)

Since the KIM API uses dynamically loaded libraries (.so's) and explicitly uses version-scripts to hide all symbols in these libraries execpt for those exclusively under the control of the KIM API, there should be no danger of symbol collisions.

This is great news. I hoped this would be the case, but I did not think it was technically feasible in a portable way.
There is something interesting going on behind the scenes that I would like to learn about at some later point in time :slight_smile:

Does KIM_API_model_info() also load the module, or does it inspect it without loading it?

This function loads, extracts data, then unloads the dynamic library associated with the requested Model.

That was what I thought. Since loading multiple models is safe, this is also be safe. Good, that makes life a lot easier.

4) Is there a way to download all KIM Models compatible with the current API? Or to download all models (then I can sort them myself)? Or to get a list of all models, so I can script the download?

This is effectively on our TO-DO list; So, currently there is not an easy way of obtaining this list.

However, you could use our query interface to get the sort of information you are looking for:

That sounds scriptable to me. Off to test all the models and their compatibility with Asap :slight_smile:

Thank you very much for all your help!

Jakob

Hi Jakob,

This is great news! We're excited about adding Asap to the list of fully KIM-Compliant Simulators.

I must be honest and say that “soon” does not mean this week :slight_smile: I have a couple of other tasks that I have to give higher priority. But a release in November or December should be realistic.

Yeah. That is pretty much exactly as I expected! I certainly know how these things go...

2) Is there a way a simulator can *read* the KIM search path? This is much less important, but the simulator might use this to list the directories, and build a drop-down menu of possible models in a GUI.

Currently, NO. However, I agree that this is a desirable function. I would think that a routine that effectively provides the list of all currently available Model names would be the way to go... What do you think? This is somewhat different than what you ask for, but achieves the same thing in this example, at least.

Your suggestion is better. It should preferably also test for compatibility with the current KIM API version number.

OK, I've added this to my list...

3) Is it safe to load more than one model into the same running process?

YES. Assuming the Model/Driver fully conform to the API specification, it is safe to use multiple instances of any combination of models. For example, you can create 15 KIM API objects (via any combination of calls to KIM_API_file_init() or KIM_API_string_init()) with 5 associated with Model A, 6 associated with Model B, and 4 associated with Model C. (Further, Model B and C, could both be based on the same Model Driver D.)

Since the KIM API uses dynamically loaded libraries (.so's) and explicitly uses version-scripts to hide all symbols in these libraries execpt for those exclusively under the control of the KIM API, there should be no danger of symbol collisions.

This is great news. I hoped this would be the case, but I did not think it was technically feasible in a portable way. There is something interesting going on behind the scenes that I would like to learn about at some later point in time :slight_smile:

Yeah. The general shared library architecutre is very nice and provides significant capability for symbol versioning, hiding, etc.... I'll be happy to discuss it with you and/or point you to resources/references!

Cheers,

Ryan