Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[sirius] GH200 recipe #96

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

[sirius] GH200 recipe #96

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ce6b56f
add 1st GH200 recipe
toxa81 May 17, 2024
93b0bf8
fix name
toxa81 May 17, 2024
41339f9
change to GH200
toxa81 May 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions recipes/sirius/v7.5/gh200/compilers.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
bootstrap:
spec: [email protected]
gcc:
specs:
- [email protected]
7 changes: 7 additions & 0 deletions recipes/sirius/v7.5/gh200/config.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
name: sirius-gh200
store: /user-environment
description: The latest version of Sirius (v7.5.0) and the tools for building it, configured for GH200.
spack:
repo: https://github.com/spack/spack.git
# commit on develop that updated the sirius package.py for v7.5.0 of sirius
commit: 13b711f
Comment on lines +6 to +7
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to use a released version of Spack (0.22.0 is now out), and add the SIRIUS package in the repo/ folder if needed? I think this is the preferred way to do things.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is two topics:

  • we should add support for Spack v0.22.0 to stackinator
  • a specific commit like this is better than master (because it is more reproducible)
    • but using a tagged release (e.g. v0.21.2) or release branch (e.g. releases/v0.21) is better
    • so moving the sirius package to a repo path is preferable, if possible.

32 changes: 32 additions & 0 deletions recipes/sirius/v7.5/gh200/environments.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
gcc-env:
compiler:
- toolchain: gcc
spec: gcc
mpi:
spec: [email protected]
gpu: cuda
unify: true
specs:
- cmake
- [email protected]
- [email protected]
- py-mpi4py
- py-h5py
- py-numpy
- py-pybind11
- py-pip
- py-pyyaml
- py-scipy
- py-voluptuous
- [email protected] ~cuda
- [email protected] +python +tests +fortran +cuda +scalapack ^openblas
variants:
- +mpi
- +cuda
- cuda_arch=90
views:
default:
Comment on lines +27 to +28
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
views:
default:
views:
sirius:
link: root

view:link:root is recommended in the docs.

Do you expect users to build SIRIUS from source themselves? If yes, we need a develop view too, where SIRIUS is excluded. This will likely require some tinkering on which specs do you need to add explicitly to the view so that they are available.

It is not yet documented, but the procedure to compile from source should be added to the documentation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd skip the develop environment here. The "general public" won't build sirius, and those who do will know how to use spack upstream.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the number of root specs (and a few patches) I had to add to #95, I totally agree.

However, from a private conversation with @bcumming it seemed that a develop view is still preferred. I'll let him comment further.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have had a bit of a think about this, and how about the following:

The interfaces that you choose to provide (spack, filesystem view, modules) depend on the user community and their needs, and how the uenv maintainer intends to provide support to the users.

If you have a community that only use Spack, then you might not need views or modules for development at all.

If you have some users who will insist on "building their own" using a view or modules, then configure them in a way that will minimise your maintenance burden.

Whatever interfaces are chosen, they should be properly documented in the /docs/<uenv-name>.md docs.

packages:
- git
- perl

6 changes: 6 additions & 0 deletions recipes/sirius/v7.5/gh200/extra/reframe.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
default:
features: [sirius, mpi, openmp]
cc: mpicc
cxx: mpic++
ftn: mpifort
activation: /user-environment/env/default/activate.sh
23 changes: 23 additions & 0 deletions recipes/sirius/v7.5/gh200/modules.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
modules:
# Paths to check when creating modules for all module sets
prefix_inspections:
bin:
- PATH
lib:
- LD_LIBRARY_PATH
lib64:
- LD_LIBRARY_PATH

default:
arch_folder: false
# Where to install modules
roots:
tcl: /user-environment/modules
tcl:
all:
autoload: none
hash_length: 0
exclude_implicits: true
exclude: ['%[email protected]', 'gcc %[email protected]']
projections:
all: '{name}/{version}'