We are happy to announce the release of kim-api-v1.9.0.
* This update to the KIM API includes a significant revision to the build system. In order to simplify the build system the "in-place" build scenario and "static-link" option have both been removed. (The "static-link" option will eventually be reintroduced with improved features. If you regularly use this option, please let us know and we will try to implement this improved feature as quickly as possible.)
* Build of Models and Models Drivers must now be done AFTER the KIM API is built and installed. A new "collections-management" utility has been created to help users manage the installed Models and Model Drivers. See the INSTALL file for details.
* Support for "Simulator Models" has been added. More information on Simulator Models is coming soon!
* General bug fixes and updates have been included.
Is it possible that in connection with this, something has changed in the tar files of the model drivers?
I am still fighting with creating an EasyBuild config, and we had finally reached something that works (it was delayed by me being away in most of August). But now the SHA-256 checksum of the .tar.gz file of at least one model driver has changed (MD_853402641673_000.tgz, but it may just be the first one to be checked). Could it be that the tar.gz files are generated on the fly, and that something change when the API is updated?
Best regards
Jakob
* Build of Models and Models Drivers must now be done AFTER the KIM API is built and installed. A new "collections-management" utility has been created to help users manage the installed Models and Model Drivers. See the INSTALL file for details.
Ouch!
Currently, tbe EasyBuild downloads the API and all models, then compiles everything.
I guess I can split it up in two EasyBuilds, one for the API and one for the models.
It does not have to do with the kim-api-v1.9.0 release.
The model and driver download archive files are generated on the fly. Additionally, we allow for “metadata” changes to be made to OpenKIM items without an increment in the item version number (the last three digits of its name). Metadata changes should have zero effect on the runtime behavior of the item.
We track changes of this type in the kimprovenance.edn file. In that file we include checksums (I believe they are sha1) for each file in the items download archive.
For the item you mention, I don’t see a recent metadata update. So, it must be the on the fly creation that has changed the md5. (If the md5 had been previously stable, I might have a reason why it has recently changed: We have recently had some maintenance work done on the openkim.org server; I could speculate that this might have caused its /tmp dir to be cleaned out.)
That is going to cause problems for any build system that requires stable checksums of source files. On the other hand, I can clearly see the need to be able to update metadata without updating the model version number, the most obvious use case is replacing the reference to a preprint with a reference to the actual paper.
I can see two possible ways out.
1. Could you provide monthly archives of all KIM models and model drivers, preferably in a single file. Something like KIM_Models_20170901.tgz. If you keep the monthly archives available, then we could have an easybuild with the latest API, and one installing the latest models; to be updated independently.
2. I could make an easybuild that just installs the API, and leave it up to the users to install the models they need. I just thought it would be a nice service to the users to install all available models (it is not that big an install, after all).
We have decided that we will make efforts toward providing stable (in terms of checksum stability) archives of all Models and Models Drivers on openkim.org.
We will also plan to make occasional releases of a snapshot collection archive
containing all Models and Model Drivers active and available on openkim.org on the date of release.
We hope these will be useful to the community and make accessing and using openkim.org content more convenient.
We will begin updating our system to support this new distribution approach now, but it will likely take us some time to get it fully in place.
If you have any questions or suggestions, we would love to hear them.