Revert modules mods

[AlexanderRichert-NOAA]

Summary

Can we live without our module-related Spack tweaks?

This PR is an attempt to eliminate the need for our customizations to Spack's module-building logic. Specifically, it removes our hash length settability for providers (in the hope that we can live with having a hash in the MPI module hierarchy, because it's not something users will have to see or interact with; it's just slightly ugly). Also, it restores the .upper(...) thing for generating env variables. For packages that need a path like foo_ROOT we can put a env.set() call in setup_run_environment (is this sufficient?).

Testing

Tested on hera with hdf5%intel ^intel-oneapi-mpi. Module files are built correctly and can be loaded the usual way.

Applications affected

all

Systems affected

all

Dependencies

JCSDA/spack#400

Issue(s) addressed

Related to #436

Checklist

• This PR addresses one issue/problem/enhancement, or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.

[climbfuji]

@AlexanderRichert-NOAA I think this needs to be tested with all UFS applications as well as JEDI-Skylab (JEDI-FV3, JEDI-UFS, JEDI-MPAS). We also need @sking112 to help us testing with JEDI-NEPTUNE (I can provide instructions / a spack-stack test install for Sarah) and we need to test this with GEOS-GCM, too.

[climbfuji]

@AlexanderRichert-NOAA I think this needs to be tested with all UFS applications as well as JEDI-Skylab (JEDI-FV3, JEDI-UFS, JEDI-MPAS). We also need @sking112 to help us testing with JEDI-NEPTUNE (I can provide instructions / a spack-stack test install for Sarah) and we need to test this with GEOS-GCM, too.

I tested this with JEDI-Skylab. We'll need minor changes in JEDI (jedi-bundle and repos underneath), but these are trivial to make. We'll also need to check GEOS and NEPTUNE

[sking112]

@climbfuji I'm happy to try with neptune if you have a test install for me to use

[climbfuji]

@climbfuji I'm happy to try with neptune if you have a test install for me to use

Yes, let me do that on Nautilus.

[climbfuji]

@climbfuji I'm happy to try with neptune if you have a test install for me to use

Yes, let me do that on Nautilus.

@sking112 I compiled a test stack on Nautilus and tested it with jedi-bundle (that's a good test, because Nautilus uses tcl and not lmod). Please only use this for testing the changes to the modules and the env variables set in the spack modules, it will be removed later.

One complication of course is that this is based on spack-stack@develop, not sure how that's going to work with NEPTUNE.

Thanks for your help with testing!

umask 0022
module purge
module load slurm
module load intel/compiler/2022.0.2
module load penguin/openmpi/4.1.6/intel-classic-2022.0.2
module use /p/app/projects/NEPTUNE/spack-stack/modulefiles
module load ecflow/5.8.4

module use /p/app/projects/NEPTUNE/spack-stack/spack-stack-tst-mods/envs/unified-env/install/modulefiles/Core/
module load stack-intel
module load stack-openmpi
module load stack-python
module load jedi-fv3-env ewok-env

[sking112]

@climbfuji Can you open up permissions on /p/app/projects/NEPTUNE/spack-stack/spack-stack-tst-mods?

[climbfuji]

@climbfuji Can you open up permissions on /p/app/projects/NEPTUNE/spack-stack/spack-stack-tst-mods?

This is finally done, apologies for the delay and the hiccup. Setting umask 0022 doesn't make any difference on Nautilus it seems!

[sking112]

@climbfuji The forecast model build cannot find bacio, sp, and w3nco libs. I'm using the jedi-neptune-env/1.0.0 module. Is this expected behavior?

[climbfuji]

@climbfuji The forecast model build cannot find bacio, sp, and w3nco libs. I'm using the jedi-neptune-env/1.0.0 module. Is this expected behavior?

Can you check if your build system looks for bacio_ROOT? If it does, it should look for BACIO_ROOT instead with this change. Of course, if the cmake way of find_package(bacio) works, that would be even better.

[sking112]

@climbfuji The forecast model build cannot find bacio, sp, and w3nco libs. I'm using the jedi-neptune-env/1.0.0 module. Is this expected behavior?

Can you check if your build system looks for bacio_ROOT? If it does, it should look for BACIO_ROOT instead with this change. Of course, if the cmake way of find_package(bacio) works, that would be even better.

It does indeed look for bacio_ROOT.

@areinecke do you have a preference for handling these library paths for the neptune_atmos builds?

[climbfuji]

@grantfirl @mkavulich Heads up that with the next version of spack-stack (1.7.0), environment variables that can be used as hints for packages (bacio_ROOT for example) will be all uppercase (BACIO_ROOT) to follow the cmake/spack standards. You may need to change the DTC SCM CMakeLists.txt if you rely on these variables.

[climbfuji]

@AlexanderRichert-NOAA I merged the spack PR, please update the submodule pointer and revert .gitmodules.

@sking112 We can deal with the bacio_ROOT vs BACIO_ROOT in a follow up PR, as long as we make sure we have a solution before we roll out spack-stack-1.7.0 and/or switch to that version with NEPTUNE.

[climbfuji]

CI is currently broken, need to merge JCSDA/spack#410 after this PR to fix it