CASTEP 23.1.1 and CASTEP 24.1 #59
Comments
|
I've added these variants: and some depends_on, around the existing mpi one: (not sure if libxc is needed at runtime) Can't enable the xml variant right now because it requires FoX: A Fortran library for XML processing which isn't in Spack right now. The only fox is a C++ toolkit. (Quantum Espresso builds its own FoX). So it would need a different name if I added it. CASTEP has a cmake build system too - probably that one should be added as well (https://spack.readthedocs.io/en/latest/packaging_guide.html#writing-a-package-recipe) but not right now. I don't think the recipe builds |
|
Altered the new variants above to add the I was hoping if our source mirror was there then it would look in it for the tar file automatically - that doesn't appear to be the case so another bit of config needs adjusting. For right now, the package recipe tells it to look in the current directory for the source, so copying in there works. However, part of the filter is wrong for this version: It is because it is |
|
I confirmed that Changed to: |
|
Still got type mismatches. |
|
You can try adding |
|
I'll have a go like that temporarily. It looks like it needs adding in the package.py to FFLAGS_FOR_LIBRARIES in |
|
Though there is a |
|
Including in spec worked, as |
|
There's a |
|
Working out how to include this lot of recommended and incompatible compilers is going to be interesting...
For footnotes see README.INSTALL. |
|
Looking at https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/quantum-espresso/package.py for examples because it has lots of different kinds of conflicts. So like this? (https://spack.readthedocs.io/en/latest/basic_usage.html#version-specifier) |
|
The build stage with the source and tests are in
The module for this CASTEP install is at (Need to fix that somewhere). |
|
|
Needed to make sure Then regenerated modules. The |
|
I want to build some of the tests, so need the compiler module, plus our already-built castep: |
|
Going to use the non-build-stage untarring of castep which is in ccspapp's Scratch. Uh, I think that worked? 486 tests passed. |
|
Can look in Ends with |
|
That was all with the install that was doing I have pushed some changes to |
|
I found why the pkg-store wasn't working, mirrors need a specific structure and don't just look for the archive in that path. So on Myriad, I have added |
|
Can try auditing my package to find problems (not sure exactly what it does/doesn't pick up). Then uninstall my previous build so I can try again with the updated package recipe. |
It should mainly do static checks, like consistency of dependencies (in case you depend on non-existing versions of a package), or the use deprecated versions, etc. |
|
Deleted cached archive so we start fresh again: and done, so looks like using the |
|
I think It might even only be needed for a) building castep 19 with gcc 10+ but I'm not sure of that and would need to check with older compilers that we don't want to use to make sure. (Maybe later). |
|
Changed The gcc bit currently looks like this: |
|
Need to test the |
|
Uninstalled current build again. Removed [email protected] from Different hash, and we have the +libxc version: and the module at now includes this when it did not before: Need to rerun the tests. |
|
Those tests are all ok again - need to see if there's anything specific to libxc. |
|
Ok, there is |
So the libxc tests are fine. The MPI tests are not happy, probably need to add more options: |
|
I've just been alerted to this thread. Sorry you are having so much difficulty with the cmake build - this was new in 23.1 and there is much complexity needed to support the build and test process flexibly and fully. The first issue you found is simply that older versions of git report "Not a git repo" which was later changed to "not a git repo", and is fixed by a simple change to the regexp ("[Nn]ot a git repo") in The other issue is more concerning. The purpose of the " $ tar tf ~/Downloads/CASTEP-23.1.tar.gz | grep gitinfo.dat so something is amiss or astray with the source. I do not recommend running bin/mkbuildinfo.pl for a cmake build as this is the script for the GNU make build. We did release an update patch for 23.1 in addition to the official release, which may be downloaded from licenses.stfc.ac.uk. This ought also to fix any issues with the compile flags of the liibraries with gfortran 10 and above, as well as a couple of build issues on ARCHER2 highlighted by Andy Turner. 77c102798890a9d15faa63e9122c4d06 Castep_23.1_build_fixes.diff.gz This will still need the patch to the regexp in The cmake build is more stable in 24.1, which was released six months ago, by the way. |
|
Oh, castep.org still only has news for 23.1.1 as the most recent release so I didn't go looking if I could get a download for 24. I have castep-23.1.1.tar.bz2 which untars as castep-castep-65582dd54bf3 and I got from the official sources - possibly in June 2023? (Or at least that's the date on the tarball, I'm assuming I got it a bit later). |
|
Thanks for pointing out the out-of-date news release headline on the licenses site. 65582dd54bf3 is the git hash we tagged as Castep-23.1.1_release. But possibly created "unofficially" by some file transfer/copy? We use the GNU make target "make dist" to create the tarball, which untars into FYI, that gitinfo.dat reads I would recommend downloading and applying the patch |
|
I've attempted to sign up for the new version so I can get it and the patch - when we got the last one was definitely pre the current site, so it might have been in the transition period when the license signup was being reworked. |
|
Alrighty, got 24.1 and the updated 23.1 and fixes. |
|
Right, finally getting back to this. Going to test the outside-Spack build of 23 with the patches first. If I add Spack's git to my modules I should have the same behaviour in both cases. |
Patched things. (Note: Spack can use a gzipped patch from a url as long as you give it the sha256 for the archive as well as the expanded file). The build completed without any issues, the install still failed at libxc. Although I actually want it to use external libxc, so would need to pass it more things to make it do that. And tell Spack to build and use libxc 5.2.2 rather than 6.2.2 for this. [Actually, 5.2.3 - it only fixes one CUDA issue] |
|
Line 92 of I'll have a look at 24 since that fixed more things. |
|
Have to work out how to tell it that patches are in the source mirror (or anywhere on the local filesystem) rather than the package repo before I can install any versions via Spack. |
|
The thing I was missing was that you don't also give the filename when you want it to be a UrlPatch: |
|
While Spack is building castep 24.1 with libxc using the existing recipe, I'm having a look at making 23.1.1 use an existing libxc. While I'm at it, I should also add in python so it isn't looking at the system python2.
|
|
CASTEP 23.1.1 by hand with external libxc (Can consider the f2py later). Now the same libxc mod file isn't found by OTFG. It exists in CASTEP 24.1 in Spack Meanwhile, castep 24.1 which built its own libxc completes the build but has the same As with 23, they're all in |
|
|
|
Looking through the generated build directory's CMakeCache.txt: The mod files are all in |
|
Assuming it is analogous to this:
then I think it wants (If that exists and is usable here). https://cmake.org/cmake/help/latest/variable/CMAKE_BINARY_DIR.html
It is going to be safer to refer to |
|
None of the other LibSource do this so it shouldn't be an issue for them. |
|
Added a patch, https://github.com/UCL-ARC/hpc-spack/blob/0.22/repos/dev/packages/castep/castep_cmake_libxc.patch - needs to be added to the package.py and tested with 23 and 24. |
|
Spack has built and installed CASTEP 24.1! With libxc, built by castep. Now to see if it can 23.1 too without any additional changes. |
|
Got this for 23.1.1 - er, caching? I did update the checksums, and it is finding the source from our mirror but doesn't want to use it. |
|
Oh, maybe it is the versions, it untars as CASTEP-23.1 now and not 23.1.1. |
|
No that updated the hash but it still fails: |
|
It put it into |
|
Debug: checks for existence in the various caches and mirrors, and with hashes in the names - those are not expected to be found. Does |
|
It appears to be |
|
Ok, it makes I put a renamed copy of the patch file with the short hash into Now I need to make 23.1 its own castep_cmake_libxc.patch because it is libxc 5.2.2 there and not 5.2.3 so the directory is different. |
|
23.1 is also successfully built and has both Castep's patch and my patch applied. |
|
Testing 24.1 including mpi: Last night I accidentally ran the castep 23.1 binary with 24.1's tests and got 20 failures (476/496 passed). Which is actually slightly reassuring. Then the libxc tests: |
|
23.1 also passes: |
|
I have added castep 23 and 24 +libxc into Things that still need doing in the recipe:
|
The existing recipe covers CASTEP 19.1.1.rc2 and 21.11.
I have added the checksum for 23.1.1 in repos/dev/packages/castep/package.py
Need to check if there are any flags or variants needed for this version, if it compiles and if it works.
The text was updated successfully, but these errors were encountered: