Perlmutter is not a production resource
Perlmutter is not a production resource and usage is not charged against your allocation of time. While we will attempt to make the system available to users as much as possible, it is subject to unannounced and unexpected outages, reconfigurations, and periods of restricted access. Please visit the timeline page for more information about changes we've made in our recent upgrades.
Current Known Issues¶
For updates on past issues, see the timeline page.
Perlmutter is now available to general users. All users with an active NERSC account have been added to the Perlmutter server login. Please follow the steps below to login to the system. If you wish to obtain a NERSC account please visit our accounts page to get an overview of what kind of allocation or user account you need.
Connecting to Perlmutter¶
You can connect directly to Perlmutter with
Connecting to Perlmutter with sshproxy¶
Connecting to Perlmutter with a Collaboration Account¶
Transferring Data to / from Perlmutter Scratch¶
Perlmutter scratch is only accessible from Perlmutter login or compute nodes.
NERSC has set up a dedicated Globus Endpoint on Perlmutter that has access to Perlmutter Scratch as well as the Community and Homes File Systems at NERSC. This is the recommended way to transfer large volumes of data to/from Perlmutter scratch.
Alternatively, for small transfers you can use
scp on a Perlmutter login node.
Larger datasets could also be staged on the Community File System (which is available on Perlmutter) either with Globus, or a
rsync on a Data Transfer Node. Once the data is on the Community File System, you can use
rsync from a Perlmutter login node to copy the data to Perlmutter scratch.
Caveats on the system¶
Last Updated: Dec 10th, 2021.
- Static compilation isn't officially supported by NERSC, but we have outlined some instructions under the static compilation section in the compiler wrappers documentation page.
- MPI/mpi4py users may notice a
mlx5error that stems from spawning forks within an MPI rank, which is considered undefined/unsupported behavior.
PrgEnv-gnuusers when using a GPU enabled code (gcc and nvcc) you might have to load a compatible gcc version for the respective
cudatoolkitinstallation. Please see our gcc compatibility section for additional details.
- Users may notice MKL-based CPU code runs more slowly. Please try
module load fast-mkl-amd.
Preparing for Perlmutter¶
Please check the Transitioning Applications to Perlmutter webpage for a wealth of useful information on how to transition your applications for Perlmutter.
Perlmutter uses Slurm for batch job scheduling.
To run a job on Perlmutter GPU nodes, you must submit the job using a project GPU allocation account name, which ends in
m9999_g). To run a job on Perlmutter or Cori CPU nodes, use an account name without the trailing
- Lists of available queues as well as their time and node limits can be found on our queue policies on Perlmutter page
- Find example job scripts on our running jobs on Perlmutter's GPU nodes page
Below you can find general information on how to submit jobs using Slurm and monitor jobs, etc.:
GPU Binding with many MPI processes¶
Bug in Cray MPICH may require GPU binding for jobs with many MPI ranks
Due to an outstanding bug with our vendor, users with many MPI ranks may also require GPU binding. This is because the MPI ranks are incorrectly allocating GPU memory, and too many MPI ranks that allocate this memory will cause the program to segfault (this segfault might happen during execution, or before the first statement is executed, and may happen only when multiple nodes are used). One workaround is to use gpu-binding to evenly spread the allocated memory. Here is an example of using gpu-binding in a 4 node job:
srun --ntasks=32 --ntasks-per-node=8 -G 4 --gpu-bind=single:2 python -m mpi4py.bench helloworld
Profiling with hardware counters¶
NVIDIA Data Center GPU Manager (dcgm) is a light weight tool to measure and monitor GPU utilization and comprehensive diagnostics of GPU nodes on a cluster. NERSC will be using this tool to measure application utilization and monitor the status of the machine. Due to current hardware limitations, collecting profiling metrics using performance tools such as Nsight-Compute, TAU, HPCToolkit applications that require acess to hardware counters will conflict with the DCGM instance running on the system.
To invoke performance collection with
ncu one must add
dcgmi profile --pause / --resume to your scripts (this script will work for single node or multiple node runs):
srun --ntasks-per-node 1 dcgmi profile --pause srun <Slurm flags> ncu -o <filename> <other Nsight Compute flags> <program> <program arguments> srun --ntasks-per-node 1 dcgmi profile --resume
Running profiler on multiple nodes
The DCGM instance on each node must be paused before running the profiler. Please note that you should only use 1 task to pause the dcgm instance as shown above.