Dear Developers,
Currently, if a user requests -DPKG_KIM with CMake, but the kim-api library can’t be found, the CMake script will automatically enable the DOWNLOAD_KIM option. We think it would be better if DOWNLOAD_KIM was only enabled when explicitly requested, and if a user tries to build with -DPKG_KIM=yes -DDOWNLOAD_KIM=no (default), and a pre-installed KIM API is not found, then configuration fails with an informative error message.
We believe this would eliminate a possible pain point of users accidentally ending up with multiple KIM-API installations and not understanding why LAMMPS isn’t finding the KIM models they’ve installed. I believe I’ve heard Axel say that the DOWNLOAD_KIM option should only be used for testing (sorry if I’m misquoting), so making it impossible to enable accidentally makes sense to me.
Would the LAMMPS developers accept such a change if I proposed it in a PR?
Cheers, ilia
This would create a different behavior than for any other package and thus result in inconsistent behavior. Thus instead, I would suggest to improve the documentation so that it becomes clear that the automatic download (while desirable for most cases) is less desirable for the KIM package. As for the “informative error message”, I am not certain if that actually will work well. Observations from the forum (which are biased because people that read and understand the documentation with sufficient care won’t post because of compilation/configuration failures) show that such a change will likely create as much confusion and extra explanation effort than the current setup. That said, I won’t mind adding a warning, e.g. like it is being created when compiling with the INTEL package without the Intel compilers (much to the confusion of less experienced users, the package is optimized for utilizing the extended vectorization capabilities of the Intel compilers and the resulting executables, if compiled with the suitable architecture settings, will happily run with maximum efficiency also on non-Intel hardware, but the other ways around: GCC or Clang on Intel hardware, will result in degraded performance). Another possible approach would be to contribute a curated CMake preset file for the specific purpose of compiling/configuring LAMMPS for OpenKIM.
That said, at some future point, we want to restructure the whole automatic download infrastructure and support users without direct internet access in a less hack-ish way than what is currently done with the scripts in the tools/offline folder. At that point, a re-assessment of the defaults and perhaps a global setting or different presets will all be back on the table.
Got it, glad I asked! I will add changes to the documentation and a CMake warning without making any functional changes to the current CMakeLists.