After a busy summer and fall, it is high time to update my Effective Medium Theory model driver (based on the ASAP code, https://wiki.fysik.dtu.dk/asap) from API version 1.0.1 to 1.1.1. Unfortunately, I ran into a small problem.
The model driver does not know which elements the models are going to support, nor how many. At the KCC last spring we discussed these problems, and obviously the mechanism supporting this has been improved. In version 1.0.1 this was handled by some text to manipulation (probably sed scripts in the Makefile system), in particular the model driver's .kim file contained a section like this
Great to hear from you and thanks for your question.
The model driver does not know which elements the models are going to support, nor how many. At the KCC last spring we discussed these problems, and obviously the mechanism supporting this has been improved. In version 1.0.1 this was handled by some text to manipulation (probably sed scripts in the Makefile system), in particular the model driver's .kim file contained a section like this
#######################################################################################################
SUPPORTED_ATOM/PARTICLES_TYPES:
# Symbol/name Type code
where the SPECIES names were replaced by actual chemical symbols by the model Makefile (and the weakness was the fixed number of these).
How should this be handled in the new API? Is it still handled by a (different) placeholder in the .kim file of the model driver, or is it somehow handled in the model initialisation?
It is still handled by placeholders. The new form looks like
Yes, 999 different elements should be enough for most uses
One question, though. How do we handle that the model driver does not know how many elements the model will support?
There are (at least) two ways for the Driver to find out how many elements the model supports. (There are probably some other options too, but they are not currently coming to mind.)
* in model_init() use a call to KIM_API_get_model_partcl_typs(). This function returns the number of particle types defined by the Model and a list of the names.
* Include the number of types as a parameter in the Model's parameter file. Then read in this number as part of the model_init().
There are a couple of options for how the Model Driver handles the variable number of elements once it knows the exact number that a Model supports.
* dynamically allocate all required arrays
* define a maximum number of supported elements and if the number provided by the Model is too big, then give an error in the model_init() routine and fail...
Thank you very much, that makes sense. How do I handle it in the .kim file, though? The make system seems to use a fixed number of placeholders for the species that the model makefile then replaces with actual elements. How does the variable numbers work here? Should there just be "enough", and the remainder then end up with the generic names?
Thank you very much indeed for porting my model driver to the newest API. I have incorporated your changes in the Asap source code, the OpenKIM modules are generated from the original source code by a small Python script. I will add a few improvements and fix a rather serious bug (also present in the original version) before resubmitting the newest version to OpenKIM.
Thank you very much, that makes sense. How do I handle it in the .kim file, though? The make system seems to use a fixed number of placeholders for the species that the model makefile then replaces with actual elements. How does the variable numbers work here? Should there just be "enough", and the remainder then end up with the generic names?
Yes, of course, that is a good question. In fact, the make system will remove any unused spec lines in the Model Driver's template kim file.
So, the Model Driver should list the maximum number of spec lines that it can support (up to 999) in its template kim file.
A Model should list just those elements that it will support in its Makefile. The make system will then perform the substitutions and remove all the unused spec lines, so that the final model kim file contains just the number of spec lines that are specified by the Model.
Thank you very much indeed for porting my model driver to the newest API. I have incorporated your changes in the Asap source code, the OpenKIM modules are generated from the original source code by a small Python script. I will add a few improvements and fix a rather serious bug (also present in the original version) before resubmitting the newest version to OpenKIM.
Thanks for all your help. I have now updated the Asap EMT potential to OpenKIM API 1.1.1, and added another parametrisation so there are now two models using the parameters: The standard EMT and a set of parameters for CuMg and CuZr bulk metallic glasses. I have also renamed them to conform with the OpenKIM naming conventions.
