Frequently Asked Questions

How do I cite the KIM project?

To cite the overall project and website use:

  • E. B. Tadmor, R. S. Elliott, J. P. Sethna, R. E. Miller, and C. A. Becker. Knowledgebase of Interatomic Models (KIM). https://openkim.org, 2011.

You can also cite the following publications describing the KIM project:

  • E. B. Tadmor, R. S. Elliott, J. P. Sethna, R. E. Miller and C. A. Becker, "The Potential of Atomistic Simulations and the Knowledgebase of Interatomic Models" JOM, 63, 17 (2011).

  • E. B. Tadmor, R. S. Elliott, S. R. Phillpot and and S. B. Sinnott, "NSF Cyberinfrastructures: A New Paradigm for Advancing Materials Simulations", Current Opinion in Solid State & Materials Sciences, 17, 298-304 (2013).


I sometimes get a certificate error when I visit openkim.org. Why is this happening and what can I do about it?

You're likely using Internet Explorer on Windows XP. Please upgrade to Google Chrome or Firefox.

The webserver uses Server Name Indication (SNI) which is not available on many older browsers and operating systems. If you're interested in more details about this implementation you can read more about SNI and why it's required here: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

If you would like assistance in discovering what needs upgrading, we recommend visiting the following link and sending us the results: https://sni.velox.ch/


How is a user meant to use a KIM-compliant interatomic Model?

In our view, a typical user would already have their favorite molecular simulation code (which has implemented a KIM-compliant binding for access to OpenKIM Models) installed on their system. (The binding would use the openkim-api package which is available from https://openkim.org/kim-api). At some point the user finds themselves interested in studying some property of a new (to them) material system. They would then go to https://openkim.org, use the search tools to find the "best" available Model for simulating the property of interest for the material of interest. Once a Model is selected, they would download it from its OpenKIM.org webpage and unpack it into a specific directory where the simulation code stores its OpenKIM Models. Next, they would compile the Model (and possibly recompile the simulation code, if it is statically linked). Finally, they are ready to use the simulation code with the newly obtained and installed Model to perform the science that they are really interested in doing.


Can one give an example of a test where it is really mandatory to specify the neighbor lists in order to compute a physical observable?

This is a good but complicated question. In spirit, you are correct; neighbor lists are purely for computational efficiency. However, by including them in the api we avoid many other difficulties. For example, without neighbor lists we would have to create and define many ways to describe boundary conditions (orthogonal periodic box, general periodic box, general space group crystal specification, twist bc's, etc., etc., etc.) Each special case would need to be identified, a standard description defined, and the community would need to agree on the definition and description. Then EACH model (or its associated Model Driver) in the KIM system would need to be modified to support the new bc.

By using the general idea of neighbor lists and "contributing particles" we have adopted an abstraction that allows for support of a very wide range of situations. We believe that this will ultimately lead to a situation where the majority of KIM Models work with a majority of KIM Tests.


Why does the api require that neighbor-list information be passed between the Test and Model?

Elaboration: Unless some tests really need the neighbor lists to compute some physical quantity, it would be a lot easier to handle them completely in the model realm. It is good that the kim project provides some infrastructure for handling neighbor lists, and parameters describing the boundary conditions are unavoidable parts of the API. My point is that the API would just become a lot more attractive if the neighbor-list code were factored out and provided to model writers as an independent library. It would also make the tests easier to write because they don't have to worry about neighbor lists anymore. Other codes (ASE, CP2K, …) that have a clear separation between PES model (DFT, force field, …) and application (MD, MC, static computations, …) typically keep the neighbor lists on the model side of the fence.

The trouble here is that the Model really should not have to worry about how neighbor lists are updated. In fact, the Model can't know the best way to update a neighbor list. For example, in an MD Test the atoms typically move only a little bit between energy/force calculations. So, often neighbor lists can be updated only every n steps of integration. In contrast, in a Monte Carlo simulation the type of MC move determines if neighbor lists need to be updated. Some moves may require all neighbor lists to be updated, whereas others may require only certain lists to be updated. In short, our view is that the Test is the only entity that really knows how to efficiently construct and update the neighbor lists.


How does one make good use of PARAM_FIXED_* in the model descriptor file? Can one give a typical example of a situation where these parameters are accessed by a Test?

There is no general way for a Test to do this (because each Model is free to define whatever PARAM_FIXED_* values it likes). However, consider the following. The Model Driver "wonky_pair_potential". This Model Driver takes three parameters: A, B, and C. From these three parameters it defines the pair interaction as a very complicated (especially for efficiency of numerical evaluation) functional form. The Model Driver stores free parameters: PARAM_FREE_A, PARAM_FREE_B, PARAM_FREE_C. To improve its numerical efficiency, the Model Driver creates a numeric spline of its pair function and stores the energy/distance values for each knot in the spline as part of the vector parameters PARAM_FIXED_knot_dist and PARAM_FIXED_knot_energy.

Now, a Test that is designed to work with "wonky_pair_potential" can take advantage of the knot values by accessing the PARAM_FIXED_knot* arrays directly, BUT it should not change these values. Instead it should change the value(s) of PARAM_FREE_{A,B,C} and let the wonky_pair_potential code regenerate the appropriate PARAM_FIXED_knots values.


Are periodic models without neighbor-lists supported, e.g. when the model takes care of its own neighbor lists or when it uses completely different approaches to evaluate energy, forces, virial, ...?

No. However, if there is enough interest and a strong enough argument (against the sort of thing we say here) for such a situation, we would be willing to add a new NBC that would support the situation of interest.


In the tests based on MiniMol (see bootcamp), a .kim descriptor file is written on the fly. Is this considered as a proper way to implement tests? It seems a bit awkward.

This is the "best" way to create what we would call a "KIM simulator". That is, a general purpose Test (for example LAMMPS). For Tests that are meant to be part of the openkim.org automatic computation pipeline, this approach is not appropriate (here a static .kim file is required).

We agree that there is some awkwardness to the approach, but the alternative is to devise a separate hand-shaking system and we have concluded that this would be more complicated than the current approach.


I ran into a gfortran cray pointer bug during the third exercise of the bootcamp. In the example ex_model_Ar_P_MLJ_MI_OPBC_H_F.F90, the line 'model_cutoff = model_Pcutoff' is ignored by gfortran 4.6.3 (Ubuntu 12.04) with -O3. Reverting to -O0 fixes the problem, but it is obviously not the ideal solution. Does someone have a better solution?

Yes. Actually we are aware of this. It is a gfortran bug. See this thread (http://gcc.gnu.org/ml/fortran/2012-06/msg00077.html) on the gfortran mailing list. The bug is associated with certain types of optimizations that are turned on by default starting with the 4.6 series of releases. There was not much success in identifying a good solution. We hope to move to Fortran 2003's C bindings soon.