{chem}[foss/2019a,intel/2019a] ASAP3 v3.11.10, kim-api v2.1.2, openkim-models v20190725, ... w/ Python 3.7.2#8786
Conversation
….11.10-intel-2019a-Python-3.7.2.eb, kim-api-2.1.2-foss-2019a.eb, kim-api-2.1.2-intel-2019a.eb, openkim-models-20190725-foss-2019a.eb, openkim-models-20190725-intel-2019a.eb, ASE-3.18.0-foss-2019a-Python-3.7.2.eb, ASE-3.18.0-intel-2019a-Python-3.7.2.eb and patches: ASAP3-3.11.10-Respect-CFLAGS-for-EasyBuild.patch
|
This makes ASAP3 available for the foss and intel 2019a toolchains. It also includes the newest KIM API and the OpenKIM models (ping @ellio167). I have included the same version of ASE as in #8768 as otherwise the self-test would fail. Git should handle this duplication gracefully in the PR merged last. |
|
@schiotz I'm not a fan of changing software names. in any case it should be consistent. |
|
Hi @smoors I certainly see your point, but I think changing the names to be consistent with all other package managers should be done now, while there is not a bunch of software depending on it. So we avoid situations like the packages for Jupyter being called IPython because once upon a time that was the name. The names @ellio167 could you comment on this, please? |
|
Yes, what @schiotz says is correct. We have been able to largely standardize the package names across system: openkim-models: As well as within https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages/kim-api and https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages/openkim-models It seems desirable to have easybuild use the same names... |
|
@schiotz ok, fair enough. |
|
Closing and reopening to trigger new self-test (for EB 4.0). |
|
@boegel Can I do anything to get this one merged? |
|
@smoors Thank you for looking into it. I have removed the ASE configs (I though git handled that gracefully, but perhaps it would have introduced a change in the files). Next time I will avoid such duplication. |
|
Test report by @smoors |
|
Going in, thanks @schiotz! |
| ('kim-api', '2.1.2'), | ||
| ] | ||
|
|
||
| use_pip = False |
There was a problem hiding this comment.
@schiotz Just wondering, which issues did you run into with pip install that made you use use_pip = False here?
There was a problem hiding this comment.
Asap installs a version of the python executable linked with MPI (called asap-python, needed for parallel simulations only), this does not get installed properly when using pip, since pip assumes it is a script, and tries to read the file and replace the hash-bang in the first line with the right path to the python executable. But since it is not a script but an executable, it goes wrong.
The main GPAW developer is working on fixing this in gpaw so building a special executable is not necessary, but there still seems to be problems on some combinations of architectures and MPI versions. Eventually, I am going to borrow his solution for asap, but it does require some work.
There was a problem hiding this comment.
Thanks a lot for the clarification!
(created using
eb --new-pr)