An important objective of the KIM project is to test the predictions of interatomic models (IMs) stored in the OpenKIM Repository for a variety of properties of interest to materials researchers. This is accomplished through a suite of KIM Tests, each of which computes one or more properties (conforming to a KIM Property Definition). A KIM Test is coupled with all compatible IMs in openkim.org. The results are added to the OpenKIM Repository where they can be viewed on Model pages through embedded visualizations and in text-based "property synopses" (click "expand" in the Test results table). Any new IMs uploaded to openkim.org will be similarly tested.
The long-term objective of the KIM project is for Tests archived in openkim.org to become standard rigorous methods for computing important material properties that can be cited in publications. The intent is for these Test to be developed by researchers with expertise related to the particular material properties with assistance from the KIM Team.
A KIM Test corresponds to the calculation of one or more specific properties for a specific material that can couple to any compatible IM (i.e. one that supports the required species and that matches the input/output requirements of the Test).
Similar to KIM Models, a KIM Test can be a stand-alone program or can be a parameter file that is read in by a more general Test Driver. For example, one can write a stand-alone Test that computes the (111) surface energy of a Au face-centered cubic (fcc) crystal. Alternatively one could create a Test Driver for the surface energy of fcc crystals that reads in a species and desired surface. Associated with this driver could be a Test for the Au(111) system comprised of a parameter file containing "Au" and "(111)". With such a Test Driver, one could easily create additional Tests for other material/surface systems. Test Drivers are preferred to stand-alone Tests due to their generality.
A Test Driver performs the following tasks: (1) read in parameters from a Test; (2) construct necessary atomic configurations (possibly using other Test Results as dependencies); (3) call an IM to obtain energies, forces and other quantities as needed and compute its associated property or properties; (4) output the properties in a standardized machine-readable form. Test Drivers can be implemented in different ways:
The Test Driver can be a computer program written in one of the languages supported by the KIM API that can directly interface with KIM Models.
The Test Driver can be a Python script that uses the KIM Calculator in the Atomic Simulation Environment (ASE).
As explained above, each Test Driver is associated with one or more Tests that define individual calculations. These Tests are coupled to compatible models by the KIM Processing Pipleine. The Pipeline is activated when a new Model or Test is uploaded to the system. It determines what calculations are required and queues them for execution. The Pipeline consists of a distributed set of virtual machines (directors and workers) running a specialized Python daemon that communicate with the Pipeline infrastructure via an asynchronous message passing framework and a message queuing system. The Pipeline automatically manages dependencies between Tests.
Developing a KIM Test Driver based on your research is an excellent way to promote your work and to make it widely available to other researchers. Your Test Driver will have a KIM ID that users can cite in publications. Tests based in your Driver will be applied to all compatible IMs in openkim.org and the results will be archived.
When developing a new Test Driver, it is recommended to start with a focused effort for a limited number of materials/cases and gradually add capabilitiesto make the driver more general and robust.
The first step is to define the material property that will be computed (unless it already exists). The current list of property definitions is here. Defining a property in rigorous fashion requires scientific expertise and is an important part of the test creation process. If a new property is to be defined, it is recommended to use an existing, similar property as a starting point and consult with the KIM Team to make the necessary changes.
Once a property definition exists, the next step is to create the Test Driver. Several possible approaches have been described above. The recommended approach is to develop ASE-based Test Drivers, which can work with both KIM Models and Simulator Models and can also be adapted to compute first principles reference data. Alternatively, a Test Driver using a particular KIM-compliant simulator (e.g. LAMMPS) or a stand-alone program can be developed. Tutorials have been prepared on how to
If you are interested in developing a new test, contact us!
Support is always available by sending an email with a question and all relevant information to
The message will be posted to the openkim google group:
Members of the OpenKIM development team actively monitor this forum and will do their best to respond to questions in a timely fashion. This forum is also used to announce minor new releases and bug fixes.