Closed iamashwin99 closed 8 months ago
Then we should update the requirements at https://github.com/fangohr/octopus-in-spack/blob/main/spack/package.py#L71
depends_on("libxc@2:2", when="@:5")
depends_on("libxc@2:3", when="@6:7")
depends_on("libxc@2:4", when="@8:9")
depends_on("libxc@5.1.0:", when="@10:")
depends_on("libxc@5.1.0:", when="@develop")
Perhaps you can ask in the octopus developer meeting which is the most recent version of libxc that should be used by Octopus (if installed through spack)?
5.2.3 is what is suggested ( and tested ) but we should bring this up.
They should have a view on this, for example: "all versions of libxc 5 are okay", or similar.
From the octopus developers meeting today, its clear that all versions of libxc 5 greater than libxc 5.1.0 is ok, but libxc6 is not supported. There used to be a site mentioning the dependencies and their versions at https://octopus-code.org/wiki/External_Libraries but its now very outdated. Its also not clear which dependencies have which version ranges supported, the version problems I mentioned in this issue ( libxc, berkeleygw, nfft@3.2.24 ) are known but we don't know which other dependencies have similar problem. This can be known only by trial and error.
We have a PR for libxc for this (#81). For the other dependencies, the current settings (mostly no restriction) seem to be fine.
Fix versions of dependencies within the spack package inorder to ensure that the interface of the dependency is consistent with what octopus expects (or was designed with ) . For eg. by default
spack spec octopus
suggests the use of libx6.0.1 which is not supported/tested by octopus developer and they only support libxc5. This was partly also the reason for the previous issue #75 . Other libraries to consider that have known breaking APIs over different versions: