This repository contains ORCD Spack environment files and how to use Spack to install new software for core and community software stacks. We will follow these recipes on the Rocky 8 nodes moving forward.
This repository contains three directories of Spack environment files:
- base_stack: Contains compilers used in core and community stacks
- core_stack: Contains core software. Same install root as base_stack.
- community_sack: Contains community software. Different install root, but has core install root as an upstream.
Each directory contains two files:
spack.yaml: Contains the install specs and configuration settings for the environment. Edit this file to add new packages to the environment.spack.lock: Contains the exact hashes of the packages installed. With this file andspack.yamlyou can exactly recreate a spack environment. Do not edit this file directly, it is managed by Spack.
There are a few supporting scripts to support installing new software:
stack-setup-env.sh: This file runs Spack'ssetup-env.shfor the production environment. It sets environment variables for the Spack Version, Home, and Install location.install_new_spack.sh: Installs a new Spack and sets$SPACK_HOME/spacksymlink to the latest install. Installs the$SPACK_VERSIONset instack-setup-env.sh.deploy_stacks.sh: Installs any software listed in the stack environments that are not already installed. Adds new compilers and creates new modulefiles as needed.make_dev_stack.sh: Creates a temporary "development" environment in/orcd/software/community/001/spack/stage/$USER/$(date +"%Y%m%d"). Links to existing spack install or installs if no existing spack exists. Createsdev_stack-setup-env.sh- copy ofstack-setup-env.shwith$SPACK_HOMEpointing to the development$SPACK_HOME. Updates local environment files to use the development space and add upstreams to existing production space.dev_install_new_spack.sh: Installs a new spack based on configuration indev_stack-setup-env.sh.dev_deploy_stacks.sh: Deploys any changes in environment files to development stacks.update_prod_stack.sh: Updates environment files to install to production place, keeping any updates to the specs section.
The production spack install space will already be set up when you add new packages. We will use a GitHub workflow to install new packages, similar to how we add new documentation pages.
- Clone this repository on Engaging (if you haven't already). If you already have a clone run
git checkout mainandgit pullto make sure you are on the main branch and have the latest updates. - Create a branch. We like to use the convention of using your initials as a prefix for the branch name. For example:
git checkout -b lm/adding_netcdf - Run “make_dev_stack.sh” to set up dev stack, this:
- Sets up a development space in /orcd/software/community/001/spack/stage/[USERNAME]/[YYYYMMDD]
- Creates symlink to existing spack installation in dev space or installs spack if it doesn’t exist
- Updates the environment configs install and module roots to do the development space and adds upstreams to production spack install
- Install root is /orcd/software/community/001/spack/stage/[USERNAME]/[YYYYMMDD]/[core/community]/pkg
- Module root is /orcd/software/community/001/spack/stage/[USERNAME]/[YYYYMMDD]/[core/community]/modulefiles
- Creates
dev_stack-setup-env.shfile for setting up dev environment
- Run
dev_deploy_stacks.shto add existing packages to dev environments 4. Run:sbatch dev_deploy_stacks.sh - Make changes, run
dev_deploy_stacks.shagain to deploy to your dev environment, test installs. See "Basic Spack Usage" below for how to make these changes. - Copy changes back to production by running
update_prod_stack.shand clean up your development space.update_prod_stack.shwill print out the command you need to do this. - Create a Pull Request for your branch. Check:
- You have run
update_prod_stack.sh- the environment files should reflect the production space, not your development space - Look at the *.yaml file diffs- do these make sense? The only thing that should have changed is the
specssection. - Pull and merge any changes from the main branch into your branch:
git checkout main,git pull,git checkout my_branch,git merge main - If all this looks good merge into the main branch. If you are not sure ask another team member to take a look.
- You have run
- Checkout the main branch and pull in your new changes (
git checkout main,git pull). Rundeploy_stacks.shto install the new packages in the production space.
We are using Spack Environments to manage our software stacks, roughly following the Stacks Tutorial.
You can run source stack-setup-env.sh to set up Spack (or source dev_stack-setup-env.sh if you are working in development), then for any of the environments run:
spack env activate path/to/core_stack
The above will activate the core stack environment located at path/to/. The production environments are kept with the production spack installation. The following commands assume you have an environment active.
To see the packages installed for core, you can run:
spack find -x
To see if a software is available through spack run:
spack list [software]
Sometimes the name will be slightly different than you expect. Once you have the name spack uses you can use the spack info command to see the full information for that software, including what versions are available, what it depends on, and which options are available for that software during build.
spack info [package]
To add a package spec to your environment run the following in an active environment:
spack add [spec]
You can also add the spec manually to the spack.yaml environment file. Be sure to include the desired compiler, architecture, and any flags.
If you want to see what dependencies will be installed with this new package, run:
spack concretize
This can be helpful if you want to make sure spack is using a particular dependency that is already installed. You don't have to run this, Spack will do this step during the install that gets called in the deploy_stacks.sh script.
After the installation is successful, lua module files are created under the module root path.
Sometimes a module isn't created during the build or you'd like to regenerate them. You can run the command:
spack module lmod refresh [package]
to recreate a specific package, or
spack module lmod refresh
to recreate all missing modules. The deploy_stacks.sh file also runs these commands for you, so modules should be created.
Here is a summary of the spack.yaml sections and the settings they use.
config:
- Set the install root path. Installation files will be automatically created in there.
- base:
/orcd/software/core/001/spack/pkg/ - core:
/orcd/software/core/001/spack/pkg/ - community:
/orcd/software/community/001/spack/pkg/
- base:
- Set install path scheme (
'{name}/{version}/{hash:7}')
compilers:
- Add compiling flags
-O3 -fPIC, which are important to optimize the performance. - When installing a new compiler it will be added to this section by the
deploy_stacks.shscript.
modules:
- Set the module root path. Module files will be automatically created in there.
- core:
/orcd/software/core/001/spack/modulefiles/ - community:
/orcd/software/community/001/spack/modulefiles/
- core:
- No dependency modules are loaded in the software module. We may need to change this later if we find it doesn't work.
- Dependency (implicit) modules are hidden- users can load them but they won't show up when you run
module avail - If needed, add environment variables under the name of a package, so that Spack will set them in a module file. It is not recommended to set
LD_LIBRARY_PATHhere.
packages:
- Set the group
orcd_rg_engagingsw_orcd-swin the permission section - This file also lists externals, system-installed libraries spack can make use of
upstreams:
- Set the core stack as an upstream of community