Update instructions for setting up spack-stack with Nvidia compilers #1462
Conversation
| xz: | ||
| buildable: false | ||
|
|
||
| Then, add the following code block to ``envs/jedi-mpas-nvidia-env/site/packages.yaml`` (because ``spack external find`` doesn't appear to work for this library): |
There was a problem hiding this comment.
I have literally no idea what I'm doing inside spack-stack, so if the experts have an idea of a better way to do this, please suggest it!
There was a problem hiding this comment.
My guess is that libbsd is coming is as a dependency of expat. I recently changed the expat requirements in config/common/packages.yaml to disable the libbsd variant. Maybe this manual change isn't needed anymore.
There was a problem hiding this comment.
I can look into this.
| @@ -642,7 +642,7 @@ Creating a new environment with Nvidia compilers | |||
| .. warning:: | |||
| Support for Nvidia compilers is experimental and limited to a small subset of packages of the unified environment. The Nvidia compilers are known for their bugs and flaws, and many packages simply don't build. The strategy for building environments with Nvidia is therefore the opposite of what it is with other supported compilers. | |||
|
|
|||
| In order to build environments with the Nvidia compilers, a different approach is needed than for our main compilers (GNU, Intel). Since many packages do not build with the Nvidia compilers, the idea is to provide as many packages as possible as external packages or build them with ``gcc``. Because our spack extension ``spack stack setup-meta-modules`` does not support combiniations of modules built with different compilers, packages not being built with the Nvidia compilers need to fulfil the two following criteria: | |||
| In order to build environments with the Nvidia compilers, a different approach is needed than for our main compilers (GNU, Intel). Since many packages do not build with the Nvidia compilers, the idea is to provide as many packages as possible as external packages or build them with ``gcc``. Because our spack extension ``spack stack setup-meta-modules`` does not support combinations of modules built with different compilers, packages not being built with the Nvidia compilers need to fulfil the two following criteria: | |||
There was a problem hiding this comment.
This is actually no longer true. We now do support building certain packages with a different compiler. We use this with intel/oneapi as preferred compilers, for example, where gcc is the fallback. But, for each of the packages that we use the fallback compiler, we need to check carefully if that is ok (e.g. it can't be a package that depends on MPI, for example). If this is helpful, I can talk you through this next week.
There was a problem hiding this comment.
Ah, interesting! I would like to chat and better understand the implications of this. I will not have any time next week, but perhaps on the week of the 27th?
There was a problem hiding this comment.
Sounds good, please ping me on slack (I will forget, 100% guaranteed)
| xz: | ||
| buildable: false | ||
|
|
||
| Then, add the following code block to ``envs/jedi-mpas-nvidia-env/site/packages.yaml`` (because ``spack external find`` doesn't appear to work for this library): |
There was a problem hiding this comment.
My guess is that libbsd is coming is as a dependency of expat. I recently changed the expat requirements in config/common/packages.yaml to disable the libbsd variant. Maybe this manual change isn't needed anymore.
Summary
This PR brings the Nvidia instructions a bit more up-to-date.
On develop, the instructions only worked with
34bfda12[email protected]With this PR, these constraints are updated to the slightly more recent
26901af[email protected]The instructions have just as many, if not more, caveats than before; however this is a bit more up-to-date and hopefully a bit easier of a starting point for future ... toil.
Testing
Describe the testing done for this PR.
Applications affected
List all known applications (UFS WM, JEDI, SRW, etc.) intentionally or unintentionally affected by this PR.
Systems affected
List all systems intentionally or unintentionally affected by this PR.
Dependencies
If there are PRs that need to be merged before or along with this one, please add "- [ ] waiting on LINK_TO_PR" for each of them
Issue(s) addressed
Link the issues addressed or resolved by this PR (use
Fixes #???for fully resolved issues)Checklist