nvc++ stdpar (NEB image forces)¶

OpenCC in the SURF notes is nvc++, not a library. GPU work there is nvc++ -mp=gpu / -stdpar=gpu, and for QMCPACK QMC_GPU="openmp;cuda". That last flag is a QMCPACK CMake option. It is not an eOn meson option.

What eOn offloads¶

The NEB image-force loop is already std::for_each(std::execution::par, …) behind -DEON_PARALLEL_NEB. Two ways to turn that on:

Meson option	Compiler	Backend
`-Dwith_parallel_neb=true`	GCC / Clang	TBB (`libstdc++`)
`-Dstdpar=cpu`	nvc++	`-stdpar=multicore`
`-Dstdpar=gpu`	nvc++	`-stdpar=gpu` plus `-gpu=`

-Dstdpar=gpu requires Meson compiler id nvidia_hpc or pgi. GCC/Clang configure fails rather than passing a flag the linker will reject.

CXX=nvc++ meson setup /tmp/eon-stdpar \
  -Dstdpar=gpu -Dstdpar_gpu_cc=cc80,cc90 \
  -Ddefault_library=static -Db_pie=false \
  -Db_pie=false -Ddefault_library=static

nvc++ 23.7 does not implement Meson’s b_pie. Leave it off. Meson’s PGICompiler has get_pic_args and no get_pie_args, so Highway’s hwy_list_targets dies writing ninja. eOn skips the cmake Highway wrap on nvidia_hpc/pgi. The PGI linker also has no link_whole, so the configure must be -Ddefault_library=static. The login-node probe needs libatomic.so.1 from GCCcore on LD_LIBRARY_PATH. Put the build dir on a local disk: NFS home on Elja stamps files ~100 s in the future and Meson then refuses coredata.dat.

The default GPU arch list is cc80,cc90 (A100 and H100, the Snellius/Elja pair). Override with -Dstdpar_gpu_cc=cc90 or -Dstdpar_gpu_cc=native to omit -gpu=. That is the same lesson as QMCPACK QMC_GPU_ARCHS=sm_80;sm_90, written in nvc++’s flag language.

parallel = true in config.ini still fans out with one std::thread per image when EON_PARALLEL_NEB is off. Set [Potential] thread_safe = false to keep one shared Potential serial (EAM cell lists, EMT ASAP objects, Metatomic, ExtPot, SocketNWChem, and XTB already refuse shared-instance threading).

What stays on the host¶

The potential is the cost. Morse, LJ, and the other in-tree host potentials keep their atom loops on the CPU. Wrapping those loops in std::for_each(std::execution::par) is not the surf-notes path: nvc++ stdpar wants a larger data-parallel kernel (a whole image force, or a GPU potential), not a three-coordinate inner loop.

gprd_linalg_backend=stdpar is a separate GPR-dimer linear-algebra choice. It does not turn on NEB image offload.

QMCPACK vs eOn¶

On Snellius/Elja the QMCPACK GPU build is QMC_GPU="openmp;cuda" with nvc++ and CUDA 12. That string does not belong in eOn’s meson options. eOn has no OpenMP target offload and no QMC_GPU equivalent.

The SURF notes also record that device bitcode on disk is not evidence of offload (llvm-config --targets-built must list NVPTX) and that compute nodes without glibc-devel need --sysroot for a host compile. Those are site toolchain facts. They do not change eOn’s meson options.

Build the nvc++ tree on a login node that has headers. Do not compile on a compute node that lacks features.h.

On Elja the login-node probe also needs libatomic.so.1 from GCCcore on LD_LIBRARY_PATH. nvc++ 23.7 identifies to Meson as nvidia_hpc. Without that library, Meson reports that nvc++ executables are not runnable.