Remove MPI from SlaterGPU (unused; unblocks USE_MPI=OFF stack)

[joshkamm]

Part of the cross-layer MPI-optional work tracked in ZEST#92 (task E in XCtera#13; hard blocker for XCtera#11).

What

SlaterGPU contains no MPI code: no MPI_* calls, no <mpi.h> include, no target links MPI::*, and sgpu.exe links no MPI. Yet it had two vestigial MPI touchpoints:

1. CMakeLists.txt — set(USE_MPI True) + if(USE_MPI) find_package(MPI REQUIRED).
2. SlaterGPUConfig.cmake.in — find_dependency(MPI REQUIRED).

Both are removed. The config-file one mattered most: it transitively re-required MPI in every consumer at find_package(SlaterGPU) time, which blocks a USE_MPI=OFF build of the SlaterGPU → ZEST → XCtera stack.

Why

Making SlaterGPU cleanly MPI-agnostic confines USE_MPI to the ZEST/XCtera layers that actually use it (they find and link MPI themselves). This is the bottom-up first step of ZEST#92's flag-consistency work.

Verification

• USE_ACC=OFF pixi install (CPU) builds clean — libSlaterGPU.a, sgpu.exe, libio.so, libcintw.so all produced.
• No source references USE_MPI / MPI, so nothing downstream in SlaterGPU is affected.

Notes

• Built/verified locally with a pinned pixi 0.60.0 (the repo's requires-pixi minimum, which CI also uses). Current pixi 0.71.0 is incompatible with the pinned pixi-build-cmake <=0.3.8 backend — a separate infra item.

🤖 Generated with Claude Code

[joshkamm]

Verified on UM Great Lakes; approved in principle by Paul

Decision (Paul, 2026-09-30): SlaterGPU could conceivably use MPI in the future, but since it doesn't today there's no harm in removing the vestigial references, as long as nothing breaks. If SlaterGPU gains real MPI code later, re-add find_package(MPI) together with an explicit MPI dependency (see #95, options B/C, and #89 on run-exports).

Branch updated: merged current main into this branch (it was 10 commits behind; the merge was clean).

Great Lakes test (this PR merged onto main @ c98e11b, local path dependency from ZEST)

• Build: login node, pixi 0.70.0, pixi-build-cmake 0.3.11. Only module load nvhpc/24.7 was loaded, with no MPI module.
  • SlaterGPU configured and built without MPI.
  • ZEST found pixi's openmpi 5 on its own.
• GPU run: spgpu partition (A40), Slurm job 62800839.
  • SlaterGPU examples/test_output.py (lih_VK1): 3 passed
  • ZEST examples/test_zest.py: 11 passed, 6 skipped (the skipped LiH_Gaussian tests are marked stale in the repo)

What this fixes on Great Lakes (the #95 MPI facet)

Without this PR, SlaterGPU's find_package(MPI REQUIRED) needs an MPI from the environment:

• With plain nvhpc/24.7: configure fails with Could NOT find MPI, the same as Zoe's trace in Build reliability: slatergpu git-main builds fail (path-dep workaround); confirmed facet = find_package(MPI REQUIRED) #95.
• With nvhpc-openmpi4/24.7: SlaterGPU configures, but the module sets OPAL_PREFIX. That points pixi's openmpi 5 wrapper at the module's install, so the wrapper can't find its own config (Cannot open configuration file .../mpicxx-wrapper-data.txt). ZEST's find_package(MPI) then fails. That combination only builds with unset OPAL_PREFIX.

With this PR, none of those workarounds are needed.

Still open for a default (git-dependency) install on Great Lakes

The pixi cache has to live on scratch, because /home NFS gives ENOLCK on pixi's cache lock. The git checkout of SlaterGPU then sits at a path that is too long (/gpfs/accounts/lsa_root/.../pixi-cache/git-v0/checkouts/<hash>/<rev>/src/integrals/integrals.cpp, 118 characters). That triggers the kernel-name truncation in #99, so the test above used ZEST's local path = "../SlaterGPU" option. This is tracked separately from this PR.

🤖 Generated with Claude Code