Enable modules for packages not compiled with preferred compiler (update spack-stack setup-meta-modules); remove need for external ecflow#1257
Conversation
… ecflow, add external qt@5
…le for intel still works
… for principal compiler Intel
climbfuji
force-pushed
the
feature/boost_gcc4intel
branch
from
e0c6d92 to
5b75c23
Compare
…n env using one principal (preferred) compiler
climbfuji
force-pushed
the
feature/boost_gcc4intel
branch
from
5b75c23 to
5d22dd7
Compare
…mpilers.yaml if not already there and list in packages_intel.yaml (or packages.yaml if only an Intel build exists). Still todo: atlantis, gaea-c5, gaea-c6 (added notes)
…k/meta_modules.py
… .github/workflows/ubuntu-ci-x86_64-oneapi.yaml
climbfuji
force-pushed
the
feature/boost_gcc4intel
branch
from
8ac23f7 to
99aa58d
Compare
| logging.info(" ... ... appending {} to MODULEPATHS_SAVE".format(modulepath_save)) | ||
| MODULEPATHS_SAVE.append(modulepath_save) | ||
|
|
||
| # For tcl modules remove the compiler prefices from the module contents |
There was a problem hiding this comment.
This block (remove the compiler prefices for tcl) got moved up, since it is needed for all compilers - not just the preferred compiler. This allows us to skip the remainder of the loop for compilers that are not the preferred compiler.
…tack/stack/meta_modules.py
climbfuji
force-pushed
the
feature/boost_gcc4intel
branch
from
ded8f03 to
871fd3d
Compare
climbfuji
requested review from
AlexanderRichert-NOAA,
RatkoVasic-NOAA,
ashley314 and
eap
RatkoVasic-NOAA
left a comment
RatkoVasic-NOAA
left a comment
There was a problem hiding this comment.
Successfully installed intel on Hercules.
Approved.
|
I was able to install on S4, although ecflow might not have successfully compiled with 
|
|
@ashley314 Your issue may be that you still have an external ecflow in the S4 site config. You will want to remove that and make sure you have an external qt@5 instead. And you will want to remove the |
AlexanderRichert-NOAA
left a comment
AlexanderRichert-NOAA
left a comment
There was a problem hiding this comment.
This seems to work fine based on testing on my local machine (namely, loading stack-intel reveals gcc-built modules, e.g., boost).
Thanks for testing @AlexanderRichert-NOAA ! I'll wait for approval from JCSDA before I merge this. |
|
@climbfuji thanks for the suggestions. I worked with @srherbener, we removed ecflow as an external package and qt was already declared. The exclude for ecflow also needed to be removed from the modules file. We were able to then install ecflow and made it through ldmod refresh with everything looking good. Ran the meta module script, but then when trying to load the jedi environment ecflow is still not showing up. Do you have any ideas on what else is missing? 
Although still seeing only boost: |
I'll ping you in slack |
…rst for UCX bug fixes
| packages: | ||
| all: | ||
| compiler:: [[email protected]] | ||
| compiler:: [[email protected]] # todo: add gcc here |
There was a problem hiding this comment.
Just want to double check. Is the intention to wait until after the 1.8.0 release to make these changes for Gaea?
There was a problem hiding this comment.
We'll do this as part of the site config updates on the release branch and then bring it back to develop if that makes sense?
There was a problem hiding this comment.
Sure, that makes sense. Happy to approve!
| packages: | ||
| all: | ||
| compiler:: [[email protected]] | ||
| compiler:: [[email protected]] # todo: add gcc here |
There was a problem hiding this comment.
Sure, that makes sense. Happy to approve!
5 participants
Summary
Note. I pinky swear that I am going to rewrite that old
setup-meta-modulesextension that was clobbered together in an afternoon three years ago with the thinking "let's try something and then do it properly next month".This PR makes the necessary changes to the site configs and the
setup-meta-modulesextension to build certain packages with other compilers than the preferred compiler and still be able to load the module for that package. We can only do this now that we have the concept of a preferred compiler in our environments. One assumption made here is that the MPI provider, if any, is compiled with the preferred compiler (I think this is a reasonable assumption to make).Our use cases are:
bisonneeds to be compiled withgccwhen the preferred compiler isoneapi. Strictly speaking, we don't need the bison module in this case, but I tested it on my laptop and it works.ecflowandboostmust be compiled withgccwhen the preferred compiler isintel. This allows us to move away from externalecflowpackages that don't work with the proposed update of Python to3.11.7(because the externalecflowwas compiled with an old Python3.9). In this case, we need theecflowmodulefile. I tested this on the Ubuntu CI runner and on Narwhal.Caveat: I have not tested if this new capability works with packages that depend on MPI (which is compiled with the preferred compiler) but that get compiled with a different compiler (e.g. something like
intel-oneapi-mpi/2021.12.0/gcc/11.2.0when the packages using the preferred compiler would haveintel-oneapi-mpi/2021.12.0/intel/2021.12.0).Still todo:
gcccompiler used as backend for Intel for Atlantis, Gaea C5, Gaea C6packages.yamland make sure every site has an externalqt@5in itspackages.yamlFix unit test, or disable because we are going to rewrite the setup-meta-modules extension after the 1.8.0 release. Yes, this time for sure!doneTesting
Applications affected
None (no changes to how applications are run)
Systems affected
All using Intel or oneAPI compilers
Dependencies
none
Issue(s) addressed
Link the issues addressed or resolved by this PR (use
Fixes #???for fully resolved issues)Checklist
All dependency PRs/issues have been resolved and this PR can be merged.