{chem}[intel/2018b] PSI4 1.2.1 (REVIEW)#7109
Conversation
| # Tests are failing with pytest 3.9.2 | ||
| ('pytest', '3.8.2', versionsuffix), | ||
| ('networkx', '2.2', versionsuffix), | ||
| ('deepdiff', '3.3.0', versionsuffix), |
There was a problem hiding this comment.
@hajgato Please include a commented out entry for PCMSolver, and explain why it's excluded for now.
Also, why are libxc, Libint & co not included as deps (given the updates to the easyblock in easybuilders/easybuild-easyblocks#1568)?
There was a problem hiding this comment.
@boegel
I did not include libxc and Libint, because those should be installed with CMake, with specific options. The current libxc and Libint are built with configure, not with CMake, plus PSI4 have specific requirements for Libint with a unified libderiv includedir, and with a different scheme of libint-max-am and libderiv-max-am1. Further compilations, that with the CMake cannot enable r12 options for Libint. As a consequence, I should use a specific version of Libint for PSI4, (which would be not compatible with a possible future version of CP2K and a new version of libxc which was built with CMake instead of the existing configure. The moment I faced this problem, the psi easyblock was already done, and I did not delete that part.
If you wish, I can make the PSI4 specific Libint and libxc easyconfigs with the -PSI4 suffix, and/or I can delete the Libint and libxc parts from the psi easyblock.
There was a problem hiding this comment.
So what happens if we don't provide libxc and Libint as dependencies ourselves? Are they downloaded on the fly during the installation of PSI4? If so, that's a good reason to include them as dependencies instead imho, even if they are very specific to PSI4 (but we should try and make them a bit more generic if possible by not using PSI in the versionsuffix).
There was a problem hiding this comment.
@boegel
Yes, they downloaded and built automatically. I am not sure in case of libxc that it can be replaced by a generic one, as it will clash with CP2K (see for specific include dir). Maybe in the case of Libint we can make a more generic easyconfig, but then we have to change the existing Libint with ConfigureMake to CMakeMake, and I am not sure about the consequences. As I added a comment in the psi easyblock, it is possible to use the non-CMake build versions, but then one have to provide a corresponding Find<library-name>.cmake scipts. I think this would lead too far, so we do need the -PSI4 suffixes.
The basic problem is that the pirmary PSI4 distribution is with conda, so we do have to be happy that we can still build it from source.
There was a problem hiding this comment.
(especially, because configure possibilities are different in libxc with CMake and configure, not sure whats the situation in case of Libint)
I do feel that in this case the lets use all deps built by EB is just too much effort, because as a matter of fact, all extra suites should be EB build, like dkh, gdma, resp, snsmp2, etc. along with Libint, libxc, gau2grid, and pybind11) Well, this is a conswquence of a modularly built application....
There was a problem hiding this comment.
Ugh, what a mess... OK, let's leave it as is then, and revisit later when we find time for it (yeah, right...)
|
@boegel Changed CMake build type from |
|
Test report by @boegel |
|
Test report by @boegel |
|
Test report by @boegel |
|
Going in, thanks @hajgato! |
needs easybuilders/easybuild-easyblocks#1568
PCMSolver(tried1.1.12, and1.2.1versions) cannot compiled withintelcompilers, even using-O0and generic architecture.(see PCMSolver/pcmsolver#159)