Spack 1.0.2

[bmhan12]

Related PR: GEOS-DEV/GEOS#3848

This PR:

• Moves spack version to 1.0.2
• Updates uberenv submodule
• Add --no-permissions flag to build scripts so we can run them without the admin account
• Add --clean flag to clean previous build if existent
• Fix compiler order in the machine specs according to spack v1
• Bump up build_jobs for matrix and tuo
• Fix matrix arch
• Fix ATS flags for Dane and Matrix
• Add bison, ninja, and gcc-runtime to toss_4_x86_64_ib and toss_4_x86_64_ib_cray. Flex will be built via spack (relevant discussion on flex/bison: Update scotch to 7.0.8 and add/fix determinism flags #314 (comment))
• Use upstream recipe for hdf5
• Adds workaround to llvm-amdgpu recipe to get a build with said compiler working.

Note:

• Spack 1.0.2 will very likely break any spack.yaml file using the pre-1.0 compilers syntax. Spack will try to take the pre-1.0 spack.yaml and auto-convert it to a 1.0 syntax, but this does not guarantee it will work. Importantly, Spack 1.0's auto-conversion will not use the new toolchains syntax, which in Spack 1.0 is how we ensure specific compilers are used like in the pre-1.0 compilers syntax: https://spack.readthedocs.io/en/latest/toolchains_yaml.html
  • This PR only makes the 1.0 toolchains changes to the Github Actions and LC system spack.yaml environment files. Caretakers of other systems will need to update their spack.yaml environment files to use toolchains and test accordingly.
  • This PR and the following PR's are examples of how to move from pre-1.0 compilers to 1.0 toolchains:
    • Preparing the move to spack@v1 LLNL/radiuss-spack-configs#134
    • Spack 1.0.2, TPL v2025.09.0 updates, and more LLNL/axom#1673
    • Update TPLs, move to ClangEnzyme LLNL/Tribol#160
    • Spack Enzyme build LLNL/smith#1412
• Disables Sherlock jobs, which struggle to get Spack 1.0.2 bootstrapped
  • error message here: https://github.com/GEOS-DEV/thirdPartyLibs/actions/runs/18206678994/job/51859282223
  • error is similar to spack issue: -m spec: Fails due to unknown namespace spack/spack#50889 (comment) (fix unknown)
• On toss_4_x86_64_ib switches external blas/lapack from intel-oneapi-mkl to openblas due to open Spack issue: https://github.com/spack/spack/issues/49994
• On matrix there are unit test failures related to OpenMP in hypre. A fix is in-progress, will require a hypre update later.

[victorapm]

@matteofrigo5 we're having issues with the Sherlock jobs and it's not very clear what's going on.

Given it's using centos 7, which already reached EOL, how about we upgrade those images to let's say Alma/Rocky 9? Would that work for Sherlock?

[bmhan12]

@CusiniM @jhuang2601 @Bubusch @klevzoff @MichaelSekachev @bd713 @rrsettgast @victorapm
Tagged based on repo activity managing spack.yaml environment files.

Please be aware of likely breaking changes in this PR moving to Spack 1.0.2, related to the deprecation of compilers in favor of toolchains. See PR description for more details.

[victorapm]

Thanks a lot for this, @bmhan12!

I noticed Sergey's PR to upstream the scotch changes have been merged: spack/spack-packages#1692

Perhaps, we can remove our internal scotch package. @klevzoff please let us know

[klevzoff]

Thanks a lot for this, @bmhan12!

I noticed Sergey's PR to upstream the scotch changes have been merged: spack/spack-packages#1692

Perhaps, we can remove our internal scotch package. @klevzoff please let us know

Yes, if we are able to move spack_packages_commit to anything past spack/spack-packages@6690c04 we can drop our local scotch package. We can also do this later to avoid adding more work/testing to this PR - looks like now it should be easy to update spack-packages without updating Spack itself, given that they maintain a stable package API.

[Bubusch]

@CusiniM @jhuang2601 @Bubusch @klevzoff @MichaelSekachev @bd713 @rrsettgast @victorapm Tagged based on repo activity managing spack.yaml environment files.

Please be aware of likely breaking changes in this PR moving to Spack 1.0.2, related to the deprecation of compilers in favor of toolchains. See PR description for more details.

Thanks for working on the spack upgrade.
I have made a spack v1.0.2 compatible version of Pangea-4 spack configuration, shall I push it here or in another PR ?

[bmhan12]

Thanks for working on the spack upgrade. I have made a spack v1.0.2 compatible version of Pangea-4 spack configuration, shall I push it here or in another PR ?

Either way is fine with me!

I want to note that there are some unit test failures with some of the Docker images, looking into fixes/workarounds.

[Bubusch]

@bmhan12 just pushed the pangea-4 config.
Also, it's likely that I’ll remove the pangea-3 config and related builds soon (pending final decommissioning approval from project leads). So if they cause any issues, feel free to just deactivate them.

[bd713]

@bmhan12 I've just updated Pine config file.
@dkachuma @jhuang2601 Could you confirm it works for you as well? Please note that this new version relies on OpenBlas.

[jhuang2601]

@bmhan12 I've just updated Pine config file. @dkachuma @jhuang2601 Could you confirm it works for you as well? Please note that this new version relies on OpenBlas.

Thanks @bd713 for updating spack config for Pine.
I can confirm that TPLs was successfully compiled:

[+] /shared/data1/Users/j0551570/Compilation/WIP_Spack_Pine/build/gcc-11.4.1/scotch-7.0.8-jwp7nzdmrxuapttlzttus5sapcrwlkl3
==> Installing scotch-7.0.8-jwp7nzdmrxuapttlzttus5sapcrwlkl3 [56/57]
==> No binary for geosx-develop-xom5kvlh7ebqdrywrjp6q6ihdxtrjhfa found: installing from source
==> No patches needed for geosx
==> geosx: Executing phase: 'geos_hostconfig'
==> geosx: Executing phase: 'lvarray_hostconfig'
==> geosx: Successfully installed geosx-develop-xom5kvlh7ebqdrywrjp6q6ihdxtrjhfa
  Stage: 0.00s.  Geos_hostconfig: 0.01s.  Lvarray_hostconfig: 0.00s.  Post-install: 0.08s.  Total: 0.24s
[+] /shared/data1/Users/j0551570/Compilation/WIP_Spack_Pine/build/gcc-11.4.1/geosx-develop-xom5kvlh7ebqdrywrjp6q6ihdxtrjhfa
==> Installing geosx-develop-xom5kvlh7ebqdrywrjp6q6ihdxtrjhfa [57/57]

And GEOS can also be compiled and pass all unit tests there:

247/247 Test #247: testWavePropagationAdjoint1 .............................   Passed    5.52 sec

100% tests passed, 0 tests failed out of 247

Total Test time (real) = 132.58 sec

[rrsettgast]

successful builds on LC:

dane-toss_4_x86_64_ib-gcc@13.3.1.cmake
dane-toss_4_x86_64_ib-llvm@14.0.6.cmake
dane-toss_4_x86_64_ib-llvm@19.1.3.cmake

matrix-toss_4_x86_64_ib-gcc@12.1.1-cuda@12.6.0.cmake
matrix-toss_4_x86_64_ib-gcc@13.3.1-cuda@12.9.1.cmake
matrix-toss_4_x86_64_ib-llvm@19.1.3-cuda@12.9.1.cmake

tuolumne-toss_4_x86_64_ib_cray-cce@20.0.0-rocm@6.4.2.cmake
tuolumne-toss_4_x86_64_ib_cray-llvm-amdgpu@6.4.2-rocm@6.4.2.cmake

failed builds on LC:
dane-gcc-12.log
matrix-clang-14-cuda-12.6.log

[bmhan12]

failed builds on LC:

Thanks @rrsettgast ! I'll take a look at the two failures.