Add RIKYU support for SALMON

[william-dawson]

Adds RIKYU (GB200 NVL4, 4 GPUs/node) as a target system for the SALMON benchmark. [code:salmon]

1. Pinned to the optimized SALMON branch. For RIKYU only, build.sh builds FugakuNEXT-v4 on william-dawson/SALMON2 (open upstream as SALMON-TDDFT/SALMON2#1276) instead of the v.2.2.2 tag, which is 14+ months stale and predates the OpenACC tuning, the Ewald loop-tripcount fix and the multi-node CUDA-context fix. Every other system stays on v.2.2.2.

Built with nvhpc-hpcx-cuda13/26.5, -DUSE_OPENACC -DUSE_GEMM -DUSE_NCCL and -cudalib=cublas,cusolver,nccl. USE_CUDA is deliberately not used — SALMON's hand-written CUDA kernels measured slower than the OpenACC path here.

The Fujitsu MPI topology patch is now applied only on Fugaku/FugakuCN, since no other system compiles that path.

2. Added RIKYU directions. build.sh, run.sh and list.csv entries for RIKYU at 1-4 nodes (4 GPUs/node), including per-rank GPU binding via a wrapper.sh. Depends on #74 for the RIKYU system/queue config.

--mca fcoll individual is required, not a tuning knob: the restart read does one MPI_File_read_all per rank into managed memory, and OMPIO's two-phase collective path deadlocks whenever the nproc_rgrid product exceeds 2.

UCX_IB_GPU_DIRECT_RDMA=no was needed on nvhpc 26.3 to stop a multi-node hang. Ablation-tested on 26.5 at 4, 8, 16 and 32 GPUs: no longer needed, and neither is UCX_TLS=^cma.

3. Both decompositions are benchmarked. At 4 ranks/node RIKYU runs the RT loop twice and emits two results, …-orbital and …-mixed:

• orbital — nproc_ob = n_ranks, nproc_rgrid = 1,1,1, process_allocation='orbital_sequential'
• mixed — nproc_ob = nodes, nproc_rgrid = 2,2,1, process_allocation='grid_sequential', which keeps the grid split inside a node (NVLink) and spreads orbitals across nodes; the default allocation would stride icomm_r across nodes.

Orbital is currently faster at every node count measured, but mixed is what a problem with less orbital parallelism has to fall back on, so both are worth tracking.

The FOM is SALMON's own rt iterations timer, not wall clock. The one-time restart read is ~40-150 s depending on whether Lustre is cold, which swamps and reorders the comparison when two layouts run in one job. Production runs do very many steps, so the RT loop is the part being benchmarked.

4. The benchmark starts from a pre-folded restart, so the ground state is out of scope. run.sh previously computed the GS as part of the benchmark. It now reads a k-point-folded restart prepared offline and runs TDDFT only. Restarts are pre-staged per system:

system	path
RIKYU	/data1/rkp00012/CX_input/SALMON/3x3x3-folded/
RC_DGXSP	/lvs0/dne1/rccs-nghpcadu/CX_input/SALMON_2x2x2_folded/
Fugaku	/home/ra000009/data/u10035/CX_input_fugaku/SALMON_3x3x3_folded/

Fugaku's list.csv row moves from 1 node to 24 nodes as a consequence. SALMON's default restart reader (method_wf_distributor='single') does one MPI_File_read_all per rank spanning its whole orbital slice, and Fujitsu MPI's MPI-IO throws MPI_ERR_ARG on per-rank reads above ~2 GB. 24 ranks (81 orbitals/rank, ~1.5 GB/rank) is the smallest node count validated for the 3x3x3 case; going lower reintroduces the failure. This is a real vendor-specific MPI-IO limit, reproduced independently of restart provenance and of physical memory.