User Guide

Technical Summary

Expanse is a dedicated Advanced Cyberinfrastructure Coordination Ecosystem: Services and Support (ACCESS) cluster designed by Dell and SDSC delivering 5.16 peak petaflops, and will offer Composable Systems and Cloud Bursting.

Expanse's standard compute nodes are each powered by two 64-core AMD EPYC 7742 processors and contain 256 GB of DDR4 memory, while each GPU node contains four NVIDIA V100s (32 GB SXM2) connected via NVLINK and dual 20-core Intel Xeon 6248 CPUs. Expanse also has four 2 TB large memory nodes.

Expanse is organized into 13 SDSC Scalable Compute Units (SSCUs), comprising 728 standard nodes, 54 GPU nodes and 4 large-memory nodes. Every Expanse node has access to a 12 PB Lustre parallel file system (provided by Aeon Computing) and a 7 PB Ceph Object Store system. Expanse uses the Bright Computing HPC Cluster management system and the SLURM workload manager for job scheduling.

Expanse supports the ACCESS core software stack, which includes remote login, remote computation, data movement, science workflow support, and science gateway support toolkits.

Expanse is an NSF-funded system operated by the San Diego Supercomputer Center at UC San Diego, and is available through the ACCESS program.

Resource Allocation Policies

• The maximum allocation for a Principle Investigator on Expanse is 15M core-hours and 75K GPU hours. Limiting the allocation size means that Expanse can support more projects, since the average size of each is smaller.
• Science Gateways requesting in the Maximize tier can request up to 30M core-hours.

Job Scheduling Policies

• The maximum allowable job size on Expanse is 4,096 cores – a limit that helps shorten wait times since there are fewer nodes in idle state waiting for large number of nodes to become free.
• Expanse supports long-running jobs - run times can be extended to one week. Users requests will be evaluated based on number of jobs and job size. 
• Expanse supports shared-node jobs (more than one job on a single node). Many applications are serial or can only scale to a few cores. Allowing shared nodes improves job throughput, provides higher overall system utilization, and allows more users to run on Expanse.

Technical Details

Systems Software Environment

System Access

As an ACCESS computing resource, Expanse is accessible to ACCESS users who are given time on the system. To obtain an account, users may submit a proposal through the ACCESS Allocation Request System  or request a Trial Account.

Interested parties may contact the ACCESS Help Desk for help with an Expanse proposal (see sidebar for contact information).

Logging in to Expanse

Expanse supports access via the command line using an ACCESS-wide password or ssh-keys with TOTP (see setup instructions below), and web-based access via the Expanse User Portal. While CPU and GPU resources are allocated separately, the login nodes are the same. To log in to Expanse from the command line, use the hostname:

login.expanse.sdsc.edu

The following are examples of Secure Shell (ssh) commands that may be used to log in to Expanse:

ssh <your_username>@login.expanse.sdsc.edu
ssh -l <your_username> login.expanse.sdsc.edu

Notes and hints

• When you log in to expanse.sdsc.edu, you will be assigned one of the two login nodes login0[1-2]-expanse.sdsc.edu. These nodes are identical in both architecture and software environment. Users should normally log in through login.expanse.sdsc.edu, but may specify one of the two nodes directly if they see poor performance.
• Please feel free to append your public key to your ~/.ssh/authorized_keys file to enable access from authorized hosts without having to enter your password. We accept RSA, ECDSA and ed25519 keys. Make sure you have a strong passphrase on the private key on your local machine.
  • You can use ssh-agent or keychain to avoid repeatedly typing the private key password.
  • Hosts which connect to SSH more frequently than ten times per minute may get blocked for a short period of time
• Do not use the login nodes for computationally intensive processes, as hosts for running workflow management tools, as primary data transfer nodes for large or numerous data transfers or as servers providing other services accessible to the Internet. The login nodes are meant for file editing, simple data analysis, and other tasks that use minimal compute resources. All computationally demanding jobs should be submitted and run through the batch queuing system.
• Login nodes are not the same as the batch nodes, Users should request an interactive sessions to compile programs.

2FA with Authenticator Authenticator (Required)

Expanse uses two-factor authentication (2FA) when using a password to log in.  2FA adds a layer of security to your authentication process. 

Install Authenticator App:

Google Authenticator for Apple IOS

Google Authenticator for Android

Once the authenticator app has been installed, users will need to enroll and pair the 2FA device with their Expanse Account.

To enroll:

1)Go to the website https://passive.sdsc.edu

2) Select the appropriate option:

Login using Globus – Select if you are an ACCESS allocated user.  You will be redirected to the Globus OpenID connect authorization site. Please choose ACCESS CI as the organization (*not* your home institution).

 I have an invitation - Select if you are NOT an ACCESS allocated user.  You will need to contact SDSC support at consult@sdsc.edu to receive an invitation.

3) Once logged in you can manage your 2FA enrollment. Click on the “Manage 2FA” button and follow the instructions to scan the QR code. Once the pairing is complete you can close the browser.  (NOTE:  This change make take up to 15 minutes to update on the system)

4) You can login to Expanse using any ssh client. For example, from a terminal window on a Mac you can do:

ssh <your_username>@login.expanse.sdsc.edu
ssh -l <your_username> login.expanse.sdsc.edu

You will either be prompted for a password (for ACCESS users this is their ACCESS portal password) followed by a prompt for the TOTP number from your authenticator app OR if you have a ssh key in place on Expanse, and the corresponding private key loaded in your ssh-agent, you will skip straight to the prompt for your TOTP code.

Expanse User Portal

The Expanse User Portal provides a quick and easy way for Expanse users to log in, transfer and edit files, and submit and monitor jobs. The Portal provides a gateway for launching interactive applications such as MATLAB, RStudio, and an integrated web-based environment for file management and job submission. All ACCESS users with a valid Expanse allocation have access via their ACCESS-based credentials.

Modules

Environment Modules provide for dynamic modification of your shell environment. Module commands set, change, or delete environment variables, typically in support of a particular application. They also let the user choose between different versions of the same software or different combinations of related codes.

Expanse uses Lmod, a Lua-based module system. Users will now need to setup their own environment by loading available modules into the shell environment, including compilers and libraries and the batch scheduler.

Users will not see all the available modules when they run the module available command without loading a compiler. Users should use the command module spider to see if a particular package exists and can be loaded on the system. For additional details, and to identify dependents modules, use the command:

module spider <application_name>

The module paths are different for the CPU and GPU nodes. Users can enable the paths by loading the following modules:

module load cpu (for cpu nodes)

module load gpu (for gpu nodes)

Users are requested to ensure that both sets are not loaded at the same time in their build/run environment (use the module list command to check in an interactive session).

On the GPU nodes, the gnu compiler used for building packages is the default version 8.3.1 from the OS. Hence, no additional module load command is required to use them. For example, if one needs OpenMPI built with gnu compilers, the following is sufficient:

module load openmpi

Useful Modules Commands

Here are some common module commands and their descriptions:

Loading and unloading modules

Some modules depend on others, so they may be loaded or unloaded as a consequence of another module command. If a model has dependencies, the command module spider <module_name> will provide additional details.

Module: command not found

The error message module: command not found is sometimes encountered when switching from one shell to another or attempting to run the module command from within a shell script or batch job. The reason the module command may not be inherited as expected is that it is defined as a function for your login shell. If you encounter this error, execute the following from the command line (interactive shells) or add to your shell script (including SLURM batch scripts):

source /etc/profile.d/modules.sh

Account Management

Managing Your User Account

The expanse-client script provides additional details regarding project availability and usage.  The script is located at:

/cm/shared/apps/sdsc/current/bin/expanse-client

The script uses the 'sdsc' module, which is loaded by default. 

[user@login01 ~]$ module load sdsc
 

To review your available projects on Expanse resource use the 'user' parameter and '-r' to desginate a resource.  If no resouce is designated expanse data will be shown by default.

To see full list of available resources, use the 'resource' command:

[user@login02 ~]$ expanse-client resource
Available resources:
expanse
expanse_gpu
expanse_industry
expanse_industry_gpu

To review project details, use the 'project' parameter followed by an eligible project. (use -p option to report with out formatting):

Many users will have access to multiple projects (e.g. an allocation for a research project and a separate allocation for classroom or educational use). Users should verify that the correct project is designated for all batch jobs. Awards are granted for a specific purposes and should not be used for other projects. Designate a project by replacing  << project >> with a project listed in the SBATCH directive in your job script:

  #SBATCH -A << project >>

Adding Users to a Project

Project PIs and co-PIs can add/remove users(accounts) to/from a project. To do this, log in to your  ACCESS portal account and go to the Manage Allocations page.

Job Charging

The charge unit for all SDSC machines, including Expanse, is the Service Unit (SU). This corresponds to the equivalent use of one compute core utilizing less than or equal to 2G of data for one hour, or 1 GPU using less than 92G of data for 1 hour. Keep in mind that your charges are based on the resources that are tied up by your job and don't necessarily reflect how the resources are used. Charges on jobs submitted to the 'shared' partitions (shared,gpu-shared,debug,gpu-debug,large-shared) are based on either the number of cores or the fraction of the memory requested, whichever is larger. Jobs submitted to the node-exclusive partitions (compute, gpu) will be charged for the all 128 cores, whether the resources are used or not.  The minimum charge for any job is 1 SU.

Job Charge Considerations

• A node-exclusive job that runs on a compute node for one hour will be charged 128 SUs (128 cores x 1 hour)
• A node-exclusive job that runs on a GPU node for one hour will be charge 4GPU hours (4 GPU x 1 hour)
• A node-exclusive job that runs on a Large memory node for one hour will be charged 1024 SUs (2TB memory X 1 hour)
• A serial job in the shared queue that uses less than 2 GB memory and runs for one hour will be charged 1 SU (1 core x 1 hour)
• Each standard compute node has ~256 GB of memory and 128 cores
  • Each standard node core will be allocated 1 GB of memory, users should explicitly include the --mem directive to request additional memory
  • Max. available memory per compute node --mem = 249208M
• Each GPU node has 4 GPUs,  ~384GB of memory and 40 cores
  • Default resource allocation for 1 GPU =  1 GPU, 1 CPU, and 1G of memory,  users will need to explicitly ask for additional resources in their job script.
  • For max memory on a GPU node, users should request --mem = 377308M
  • A GPU SU is equivalent to 1GPU, <10CPUs, and <92G of memory.
• Multicore jobs will scale according to resource utilization
• Each large memory node has ~2 TB of memory and 128 cores
  • By default the system will only allocate 1 GB of memory per core,  explicitly use the --mem directive to request additional memory
  • Max. memory per large memory node --mem = 2055638M

Compiling Codes

Expanse CPU nodes have GNU, Intel, and AOCC (AMD) compilers available along with multiple MPI implementations (OpenMPI, MVAPICH2, and IntelMPI). The majority of the applications on Expanse have been built using gcc/10.2.0 which features AMD Rome specific optimization flags (-march=znver2). Users should evaluate their application for best compiler and library selection. GNU, Intel, and AOCC compilers all have flags to support Advanced Vector Extensions 2 (AVX2). Using AVX2, up to eight floating point operations can be executed per cycle per core, potentially doubling the performance relative to non-AVX2 processors running at the same clock speed. Note that AVX2 support is not enabled by default and compiler flags must be set as described below.

Expanse GPU nodes have GNU, Intel, and PGI compilers available along with multiple MPI implementations (OpenMPI, IntelMPI, and MVAPICH2). The gcc/10.2.0, Intel, and PGI compilers have specific flags for the Cascade Lake architecture. Users should evaluate their application for best compiler and library selections.

Note that the login nodes are not the same as the GPU nodes, therefore all GPU codes must be compiled by requesting an interactive session on the GPU nodes.

Using AMD Compilers

The AMD Optimizing C/C++ Compiler (AOCC) is only available on CPU nodes. AMD compilers can be loaded by executing the following commands at the Linux prompt:

module load aocc

For more information on the AMD compilers: [flang | clang ] -help

Using the Intel Compilers

The Intel compilers and the MVAPICH2 MPI compiler wrappers can be loaded by executing the following commands at the Linux prompt:

module load intel mvapich2

For AVX2 support, compile with the -march=core-avx2 option. Note that this flag alone does not enable aggressive optimization, so compilation with -O3 is also suggested.

Intel MKL libraries are available as part of the "intel" modules on Expanse. Once this module is loaded, the environment variable INTEL_MKLHOME points to the location of the mkl libraries. The MKL link advisor can be used to ascertain the link line (change the INTEL_MKLHOME aspect appropriately).

For example to compile a C program statically linking 64 bit scalapack libraries on Expanse:

mpicc -o pdpttr.exe pdpttr.c \
    -I$INTEL_MKLHOME/mkl/include \
    ${INTEL_MKLHOME}/mkl/lib/intel64/libmkl_scalapack_lp64.a \
    -Wl,--start-group ${INTEL_MKLHOME}/mkl/lib/intel64/libmkl_intel_lp64.a \
    ${INTEL_MKLHOME}/mkl/lib/intel64/libmkl_core.a \
    ${INTEL_MKLHOME}/mkl/lib/intel64/libmkl_sequential.a \
    -Wl,--end-group ${INTEL_MKLHOME}/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.a \
    -lpthread -lm

For more information on the Intel compilers: [ifort | icc | icpc] -help

Using the PGI Compilers

The PGI compilers are only available on the GPU nodes, and can be loaded by executing the following commands at the Linux prompt

module load pgi

Note that the openmpi build is integrated into the PGI install so the above module load provides both PGI and openmpi.

For AVX support, compile with -fast.

For more information on the PGI compilers: man [pgf90 | pgcc | pgCC]

Using the GNU Compilers

The GNU compilers can be loaded by executing the following commands at the Linux prompt:

module load gcc openmpi

For AVX support, compile with -march=core-avx2. Note that AVX support is only available in version 4.7 or later, so it is necessary to explicitly load the gnu/4.9.2 module until such time that it becomes the default.

For more information on the GNU compilers: man [gfortran | gcc | g++]

Notes and Hints

• The mpif90, mpicc, and mpicxx commands are actually wrappers that call the appropriate serial compilers and load the correct MPI libraries. While the same names are used for the Intel, PGI and GNU compilers, keep in mind that these are completely independent scripts.
• If you use the PGI or GNU compilers or switch between compilers for different applications, make sure that you load the appropriate modules before running your executables.
• When building OpenMP applications and moving between different compilers, one of the most common errors is to use the wrong flag to enable handling of OpenMP directives. Note that Intel, PGI, and GNU compilers use the -qopenmp, -mp, and -fopenmp flags, respectively.
• Explicitly set the optimization level in your makefiles or compilation scripts. Most well written codes can safely use the highest optimization level (-O3), but many compilers set lower default levels (e.g. GNU compilers use the default -O0, which turns off all optimizations).
• Turn off debugging, profiling, and bounds checking when building executables intended for production runs as these can seriously impact performance. These options are all disabled by default. The flag used for bounds checking is compiler dependent, but the debugging (-g) and profiling (-pg) flags tend to be the same for all major compilers.

Running Jobs on Expanse

Expanse uses the Simple Linux Utility for Resource Management (SLURM) batch environment. When you run in the batch mode, you submit jobs to be run on the compute nodes using the sbatch command as described below. Remember that computationally intensive jobs should be run only on the compute nodes and not the login nodes.

Expanse places limits on the number of jobs queued and running on a per group (allocation) and partition basis. Please note that submitting a large number of jobs (especially very short ones) can impact the overall  scheduler response for all users. If you are anticipating submitting a lot of jobs, please contact the SDSC consulting staff before you submit them. We can work to check if there are bundling options that make your workflow more efficient and reduce the impact on the scheduler.

The limits for each partition are noted in the table below. Partition limits are subject to change based on Early User Period evaluation.

Requesting interactive resources using srun

You can request an interactive session using the srun command. The following example will request one regular compute node, 4 cores,  in the debug partition for 30 minutes.

srun --partition=debug  --pty --account=<<project>> --nodes=1 --ntasks-per-node=4 \
    --mem=8G -t 00:30:00 --wait=0 --export=ALL /bin/bash

The following example will request a GPU node, 10 cores, 1 GPU and 96G  in the debug partition for 30 minutes.  To ensure the GPU environment is properly loaded, please be sure run both the module purge and module restore commands.

login01$ srun --partition=gpu-debug --pty --account=<<project>> --ntasks-per-node=10 \
    --nodes=1 --mem=96G --gpus=1 -t 00:30:00 --wait=0 --export=ALL /bin/bash

srun: job 1336890 queued and waiting for resources
srun: job 1336890 has been allocated resources
exp-7-59$ module purge
exp-7-59$ module restore

Resetting modules to system default. Resetting $MODULEPATH back to system default.
    All extra directories will be removed from $MODULEPATH.

Submitting Jobs Using sbatch

Jobs can be submitted to the sbatch partitions using the sbatch command as follows:

 sbatch jobscriptfile

where jobscriptfile is the name of a UNIX format file containing special statements (corresponding to sbatch options), resource specifications and shell commands. Several example SLURM scripts are given below:

Basic MPI Job

#!/bin/bash
#SBATCH --job-name="hellompi"
#SBATCH --output="hellompi.%j.%N.out"
#SBATCH --partition=compute
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=128
#SBATCH --mem=0 
#SBATCH --account=<<project*>>
#SBATCH --export=ALL
#SBATCH -t 01:30:00

#This job runs with 2 nodes, 128 cores per node for a total of 256 tasks.

module purge
module load cpu
#Load module file(s) into the shell environment
module load gcc
module load mvapich2
module load slurm

srun --mpi=pmi2 -n 256 ../hello_mpi

• Expanse requires users to enter a valid project name; users can list valid project by running the expanse-client script.
• Expanse requires users to include memory ,  by using --mem=0 for compute partition the job will be allocated all the avialble memory on the node

Basic OpenMP Job

#!/bin/bash
#SBATCH --job-name="hello_openmp"
#SBATCH --output="hello_openmp.%j.%N.out"
#SBATCH --partition=compute
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=24
#SBATCH --mem=249000M
#SBATCH --account=<<project*>>
#SBATCH --export=ALL
#SBATCH -t 01:30:00

module purge 
module load cpu
module load slurm
module load gcc
module load openmpi

#SET the number of openmp threads
export OMP_NUM_THREADS=24

#Run the job
./hello_openmp

* Expanse requires users to enter a valid project name; users can list valid project by running the expanse-client script.

Hybrid MPI-OpenMP Job

#!/bin/bash
#SBATCH --job-name="hellohybrid"
#SBATCH --output="hellohybrid.%j.%N.out"
#SBATCH --partition=compute
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=128
#SBATCH --cpus-per-task=16
#SBATCH --mem=249000M
#SBATCH --account=<<project*>>
#SBATCH --export=ALL
#SBATCH -t 01:30:00

#This job runs with 1 node, 128 cores per node for a total of 128 cores.
# We use 8 MPI tasks and 16 OpenMP threads per MPI task

module purge 
module load cpu
module load slurm
module load intel
module load intel-mpi

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK

mpirun -genv I_MPI_PIN_DOMAIN=omp:compact ./hello_hybrid

#!/bin/bash
#SBATCH -p shared
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=8
#SBATCH --mem=40G
#SBATCH -t 01:00:00
#SBATCH -J job.8
#SBATCH -A <<project*>>
#SBATCH -o job.8.%j.%N.out
#SBATCH -e job.8.%j.%N.err
#SBATCH --export=ALL

export SLURM_EXPORT_ENV=ALL

module purge
module load cpu
module load gcc
module load mvapich2
module load slurm

srun -n 8 ../hello_mpi

#SBATCH --partition=large-shared
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=128
#SBATCH --cpus-per-task=1
#SBATCH --mem=2055638M

export OMP_PROC_BIND='true'

Using GPU Nodes

GPU nodes are allocated as a separate resource. The GPU nodes can be accessed via either the "gpu" or the "gpu-shared" partitions.

#SBATCH -p gpu

or

#SBATCH -p gpu-shared

When users request 1 GPU, in gpu-shared partition, by default they will also receive, 1 CPU, and 1G memory.  Here is an example AMBER script using the gpu-shared queue.

GPU job

#!/bin/bash
#SBATCH --job-name="ambergpu"
#SBATCH --output="ambergpu.%j.%N.out"
#SBATCH --partition=gpu
#SBATCH --nodes=1
#SBATCH --gpus=4
#SBATCH --mem=377300M
#SBATCH --account=<<project*>>
#SBATCH --no-requeue
#SBATCH -t 01:00:00

module purge
module load gpu
module load slurm
module load openmpi			
module load amber
pmemd.cuda -O -i mdin.GPU -o mdout.GPU.$SLURM_JOBID -x mdcrd.$SLURM_JOBID \
    -nf mdinfo.$SLURM_JOBID -1 mdlog.$SLURM_JOBID -p prmtop -c inpcrd

* Expanse  requires users to enter a valid project name; users can list valid project by running the expanse-client script.

GPU-shared job

#!/bin/bash
#SBATCH --job-name="ambergpushared"
#SBATCH --output="ambergpu.%j.%N.out"
#SBATCH --partition=gpu-shared
#SBATCH --nodes=1
#SBATCH --gpus=2
#SBATCH --cpus-per-task=1
#SBATCH --mem=93G
#SBATCH --account=<<project*>>
#SBATCH --no-requeue
#SBATCH -t 01:00:00

module purge
module load gpu
module load slurm
module load openmpi			
module load amber
pmemd.cuda -O -i mdin.GPU -o mdout-OneGPU.$SLURM_JOBID -p prmtop -c inpcrd

* Expanse  requires users to enter a valid project name; users can list valid project by running the expanse-client script.

Users can find application specific example job script on the system in directory /cm/shared/examples/sdsc/.

GPU modes can be controlled for jobs in the "gpu" partition.  By default, the GPUs are in non-exclusive mode and the persistence mode is 'on'.  If a particular "gpu"  partition job needs exclusive access the following options should be set in your batch script:

#SBATCH --constraint=exclusive

To turn persistence off add the following line to your batch script:

#SBATCH --constraint=persistenceoff

The charging equation will be:

GPU SUs = (Number of GPUs) x (wallclock time)

SLURM No-Requeue Option

SLURM will requeue jobs if there is a node failure. However, in some cases this might be detrimental if files get overwritten. If users wish to avoid automatic requeue, the following line should be added to their script:

#SBATCH --no-requeue

The 'requeue' count limit is currently set to 5. The job will be requeued 5 times after which the job will be placed in the REQUEUE_HOLD state and the job must be canceled and resubmitted.

Example Scripts for Applications

SDSC User Services staff have developed sample run scripts for common applications. They are available in the /cm/shared/examples directory on Expanse.

Job Dependencies

There are several scenarios (e.g. splitting long running jobs, workflows) where users may require jobs with dependencies on successful completions of other jobs. In such cases, SLURM's --dependency option can be used. The syntax is as follows:

[user@login01-expanse ~]$ sbatch --dependency=afterok:jobid jobscriptfile

Job Monitoring and Management

Users can monitor jobs using the squeue command.

[user@expanse ~]$ squeue -u user1

             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
            256556   compute raxml_na user1     R    2:03:57      4 expanse-14-[11-14]
            256555   compute raxml_na user1     R    2:14:44      4 expanse-02-[06-09]

In this example, the output lists two jobs that are running in the "compute" partition. The jobID, partition name, job names, user names, status, time, number of nodes, and the node list are provided for each job. Some common squeue options include:

Users can cancel their own jobs using the scancel command as follows:

[user@expanse ~]$ scancel <jobid>

Data Movement

Globus: SDSC Collections, Data Movers and Mount Points

All of Expanse's Lustre filesystems are accessible via the SDSC Expanse specific collections(SDSC HPC - Expanse Lustre ; *SDSC HPC - Projects) . The following table shows the mount points on the data mover nodes (that are the backend for ).

Storage

Overview

Users are responsible for backing up all important data in case of unexpected data loss at SDSC.

The SDSC Expanse Lustre file system (including /expanse/lustre/scratch and /expanse/lustre/project) IS NOT an archival file system. The SDSC Expanse Lustre file system IS NOT backed up. SDSC will enforce a strict purge policy on the Expanse Lustre filesystem. Project space will be purged 90 days after allocation expires. Scratch files will be purged 90 days from creation date.

Local Scratch Disk

The compute nodes on Expanse have access to fast flash storage. There is 1TB of SSD space available for use on each compute node. The latency to the SSDs is several orders of magnitude lower than that for spinning disk (<100 microseconds vs. milliseconds) making them ideal for user-level check pointing and applications that need fast random I/O to large scratch files. Users can access the SSDs only during job execution under the following directories local to each compute node:

Parallel Lustre Filesystems

In addition to the local scratch storage, users will have access to global parallel filesystems on Expanse. Every Expanse node has access to a 12 PB Lustre parallel file system (provided by Aeon Computing) and a 7 PB Ceph Object Store system, 140 GB/second performance storage. SDSC limits the number of files that can be stored in the /lustre/scratch filesystem to 2 million files per user. Users should contact support for assistance at the ACCESS Help Desk if their workflow requires extensive small I/O, to avoid causing system issues assosiated with load on the metadata server.

The two Lustre filesystems available on Expanse are:

• Lustre Expanse scratch filesystem: /expanse/lustre/scratch/$USER/temp_project
• Lustre NSF projects filesystem: /expanse/lustre/projects/

Submitting Jobs Using Lustre

Jobs that need to use the Lustre filesystem should explicitly reqeust the feature by including the following line  to their script:

#SBATCH --constraint="lustre"

This constraint can be used in combination with any other constraints you are already using. For example:

#SBATCH --constraint="lustre&persistenceoff&exclusive"

 Jobs submitted without --constraint="lustre" that need the Lustre filesystem will be scheduled on nodes without Lustre and will FAIL.

Home File System

After logging in, users are placed in their home directory, /home, also referenced by the environment variable $HOME. The home directory is limited in space and should be used only for source code storage. User will have access to 100GB in /home. Jobs should  never be run from the home file system, as it is not set up for high performance throughput. Users should keep usage on $HOME under 100GB. Backups are currently being stored on a rolling 8-week period. In case of file corruption/data loss, please contact us at ACCESS Help Desk to retrieve the requested files.

Composable Systems

Expanse also supports Composable Systems, allowing researchers to create a virtual 'tool set' of resources, such as Kubernetes resources, for a specific project and then re-compose it as needed. Expanse will also feature direct scheduler integration with the major cloud providers, leveraging high-speed networks to ease data movement to and from the cloud.

All Composable System requests must include a brief justification, specifically describing why a Composable System is required for the project.

Software

Expanse supports a broad application base with installs and modules for commonly used packages in bioinformatics, molecular dynamics, machine learning, quantum chemistry, structural mechanics, and visualization, and will continue to support Singularity-based containerization in Expanse. Users can search for available software on Expanse using the module command Expanse Modules documentation.

Citations & Publications

How to cite Expanse

We request that you cite your use of the Expanse with the following citation format, and modified as needed to conform with citation style guidelines. Most importantly, please include the Digital Object Identifier (DOI) — https://doi.org/10.1145/3437359.3465588 — that is unique to Expanse.

Example

San Diego Supercomputer Center (2025): Expanse. University of California San Diego. Service. https://doi.org/10.1145/3437359.3465588

Publications

View a list of publications resulting from the use of Expanse.