The one-off modifications for Orion and Hercules are ok for release/1.9.0. However, we don't want to merge this information back, and we need a permanent and automated solution for develop.

Agree that an automated solution is required.

spack-managed-x86-64_v3/v1.0 must be specified when creating / building the stack in order to be able to load the oneAPI compiler and MPI modules.

Given its presence in the site config files, it is necessarily added to the meta modules per spack stack setup-meta-modules.

I've looked at Lmod's inherit() function, it's not clear to me that this can be practically applied.

The interim solution in the PR is to not load spack-managed-x86-64_v3/v1.0 but instead prepend the path it sets to MODULEPATH, thus preventing

$ echo $MODULEPATH
/apps/spack-managed/modulefiles/linux-rocky9-x86_64/Core:/apps/other/modulefiles:/apps/containers/modulefiles:/apps/licensed/modulefiles

Loading spack-managed-x86-64_v3/v1.0 yields:

$ module load spack-managed-x86-64_v3/v1.0
$ echo $MODULEPATH
/apps/spack-managed-x86_64_v3-v1.0/modulefiles/Core:/apps/other/modulefiles:/apps/containers/modulefiles:/apps/licensed/modulefiles

The difference the -1.0 path, and pushenv() is intentional:

The old and new stacks are not compatible. The expectation is to load spack-managed before executing any other module use statements. pushenv is the only mechanism that allows for swapping between the two stacks that consistently removes the old tree, but returns it on unload. Using the "remove_path" function doesn't revert the changes.

I'm not sure what constitutes a repeatable and automated solution, as it's specific to certain hosts. Perhaps it would work to modify MODULEPATH (in setup.sh, or after sourcing that file) to be what's required to find the compiler and MPI modules?

How about switching to intel-oneapi-compilers/2024.1.0 instead of intel-oneapi-compilers/2024.2.1 ?
Is there anything that we have in 2024.2 that we don't have in 2024.1?

How about switching to intel-oneapi-compilers/2024.1.0 instead of intel-oneapi-compilers/2024.2.1 ? Is there anything that we have in 2024.2 that we don't have in 2024.1?

2024.1 isn't supported, there are bugs in icx and icpx if I recall correctly that prevent us from using it / building Python stacks.

Let's table this for now and let's make sure we have an issue in spack-stack to look into it after the 1.9.1 release.

The one-off modifications for Orion and Hercules are ok for release/1.9.0. However, we don't want to merge this information back, and we need a permanent and automated solution for develop.

Agree that an automated solution is required.

spack-managed-x86-64_v3/v1.0 must be specified when creating / building the stack in order to be able to load the oneAPI compiler and MPI modules.

Given its presence in the site config files, it is necessarily added to the meta modules per spack stack setup-meta-modules.

I've looked at Lmod's inherit() function, it's not clear to me that this can be practically applied.

The interim solution in the PR is to not load spack-managed-x86-64_v3/v1.0 but instead prepend the path it sets to MODULEPATH, thus preventing

$ echo $MODULEPATH
/apps/spack-managed/modulefiles/linux-rocky9-x86_64/Core:/apps/other/modulefiles:/apps/containers/modulefiles:/apps/licensed/modulefiles

Loading spack-managed-x86-64_v3/v1.0 yields:

$ module load spack-managed-x86-64_v3/v1.0
$ echo $MODULEPATH
/apps/spack-managed-x86_64_v3-v1.0/modulefiles/Core:/apps/other/modulefiles:/apps/containers/modulefiles:/apps/licensed/modulefiles

The difference the -1.0 path, and pushenv() is intentional:

The old and new stacks are not compatible. The expectation is to load spack-managed before executing any other module use statements. pushenv is the only mechanism that allows for swapping between the two stacks that consistently removes the old tree, but returns it on unload. Using the "remove_path" function doesn't revert the changes.

I'm not sure what constitutes a repeatable and automated solution, as it's specific to certain hosts. Perhaps it would work to modify MODULEPATH (in setup.sh, or after sourcing that file) to be what's required to find the compiler and MPI modules?

Several other site configs have instructions that must be run before building spack-stack environments (i.e. before source setup.sh, spack stack create env ..., etc.) and/or before loading spack-stakc modules. See https://github.com/JCSDA/spack-stack/wiki/spack%E2%80%90stack%E2%80%901.9.1-release-documentation-(placeholder), example Derecho. This is absolutely ok.

Several other site configs have instructions that must be run before building spack-stack environments (i.e. before source setup.sh, spack stack create env ..., etc.) and/or before loading spack-stakc modules. See https://github.com/JCSDA/spack-stack/wiki/spack%E2%80%90stack%E2%80%901.9.1-release-documentation-(placeholder), example Derecho. This is absolutely ok.

This makes sense, and I suspect that it will work.

I am not convinced that it fixes the loading of modules for users; the spack-stack meta modules (stack-oneapi, stack-intel-oneapi-mpi) will attempt to load intel-oneapi-compilers/2024.2.1 and intel-oneapi-mpi/2021.13.1, and for that to succeed, one must first load spack-managed-x86-64_v3/v1.0, which takes us right back to: Orion & Hercules module config issue for spack-stack-1.9.0