Getting Started on Aurora

Help Desk


NOTE: Sharing any results from Aurora publicly is forbidden without formal approval from Intel and Argonne. Email if you have questions or need clarification.

Aurora is in the very early stages of the system deployment - do not expect a production environment! 

Expect to experience:

  • Hardware instabilities – possible frequent downtimes
  • Software instabilities – non-optimized compilers, libraries, and tools; frequent software updates
  • Non-final configurations (e.g. storage, OS versions, etc.)
  • Short notice for downtimes (scheduled downtimes will be with 4 hr notice, but sometimes downtimes may occur with just an email notice). Notices go to the email list. All users with access are added to the list initially.


  • Aurora consists of multiple racks, each with many nodes, for a total of over 10,000 nodes
  • Each node consists of 2 Intel Xeon CPU Max Series (codename Sapphire Rapids or SPR) and 6 Intel Data Center GPU Max Series (codename Ponte Vecchio or PVC).
    • Each Xeon has 52 physical cores supporting 2 hardware threads per core
  • Interconnect is provided via 8 HPE Slingshot-11 NICs per node.



To gain access to Aurora, Early Science Project (ESP) and Exascale Computing Project (ECP) team members must have access to Sunspot. 

To get access to Sunspot, please see: 

Getting Help

  • Email ALCF Support at for bugs, technical questions, software requests, reservations, priority boosts, etc.
    • ALCF’s user support team will triage and forward the tickets to the appropriate technical SME as needed
    • Expect turnaround times to be slower than on a production system as the technical team will be focused on stabilizing and debugging the system
  • For faster assistance, consider contacting your project’s POC at ALCF (project catalyst or liaison)
    • They are an excellent source of assistance during this early period and will be aware of common bugs and known issues
  • ECP and ESP users will be added to a CNDA Slack workspace, where CNDA discussions may occur. An invite to the Slack workspace will be sent when a user is added to the Sunspot/Aurora resource.

Known Issues

A known issues page can be found in the JLSE Wiki space used for NDA content. Note that this page requires JLSE Aurora early hw/sw resource account for access :

Logging into Aurora user access nodes

You will be able to access the system via SSHing to This bastion is merely a pass-through erected for security purposes and is not meant to host files. Once on the bastion, SSH to It is round robin to the UANs (user access nodes).

Note that Aurora uses ALCF credentials (same as Theta, ThetaGPU, Polaris and website) and not JLSE credentials (used for Arcticus/Florentia, JLSE wiki, website, and CNDA Slack workspace)

Home and project directories

  1. Home mounted as /home, shared on uans and computes. Bastions have a different /home which is on Swift (shared with Polaris, Theta, Cooley). Default quota is 50 GB.

  2. Project directories are on /lus/gecko/projects

    • ALCF staff should use /lus/gecko/projects/Aurora_deployment project directory. ESP and ECP project members should use their corresponding project directories. The project name is similar to the name on Theta/Polaris with an _CNDA suffix (for eg: projectA_aesp_CNDA, CSC250ADABC_CNDA). Default quota is 1 TB. The project PI should email if their project requires additional storage.

Home and Project directories are on a Lustre file system called Gecko.


Default home quota is 50 GB.  Use this command to view your home directory quota usage: 



Aurora has PBSPro. For more information on using PBSPro for job scheduling, see PBSPro at ALCF.

There are two production execution queues "workq" and "diag" and one debug queue called "debug" on Aurora. In addition, there is a routing queue called "workq-route", that can be used to hold multiple jobs which get routed to workq. Note that users can submit jobs to workq directly and do not have to use the routing queue (workq-route) if they don't need to.

  • diags queue is a lower priority queue, intended for operational diagnostics, that will run jobs when there are no jobs queued in workq. Access to the diag queue is restricted. Email if you have a need to use this queue and provide a write-up of your use-case.

For example a one node, interactive job on workq can be requested for 30 min with:

qsub -l select=1 -l walltime=30:00 -A Aurora_deployment -q workq -I

Queue Policies:

For workq queue:

  1. max job length: 2 hr 
  2. max job size : 64 - (nodes that are down) - (nodes that have broken/validation flags set on them [currently 4]) - (4 debug nodes) - (4 validation nodes)
  3. interactive jobs have a shell time out of 30 mins which will cause idle interactive shells to exit if idle for more than 30 minutes
  4. max number of jobs: 1 running and 1 queued

For workq-route queue (routing queue):

  1. max job length: 2 hr 
  2. max job size : 64 - (nodes that are down) - (nodes that have broken/validation flags set on them [currently 4]) - (4 debug nodes) - (4 validation nodes)
  3. max number of jobs queued: 30

For diag queue:

There are no restrictions for the diag queue. It is a lower priority queue that will run jobs when there are no jobs queued in workq or debug queues, and intended for operational diagnostics. Access to diags queue is restricted. Email if you have a need to use this queue and provide a write-up of your use-case.

For debug queue:

  1. max job length: 1 hr
  2. max job size :  1 node  (a total of 4 nodes are reserved for the debug queue)
  3. interactive jobs have a shell time out of 30 mins which will cause idle interactive shells to exit if idle for more than 30 minutes
  4. max number of jobs : 1 running and 1 queue

Allocation usage

The allocation accounting system sbank, is not yet installed on Aurora. 

  • To obtain the usage information for all your projects, issue the sbank command on another ALCF where sbank is installed, such as Polaris where
    • sbank-list-allocations -r aurora

For more information, see this page:

Data Transfer

Currently, scp and SFTP are the only ways to transfer data to/from Aurora. 

As an expedient for initiating ssh sessions to Aurora login nodes via the bastion indirect nodes, and to enable scp from remote hosts to Aurora login nodes, add the following lines to your ~/.ssh/config file on the remote host. You should do this on your laptop/desktop, from which you are initiating ssh login sessions to Aurora via bastion, and on other non-ALCF host systems from which you want to copy files to Aurora login nodes using scp.

Replace id_rsa with the name of your own private ssh key file. When you run the ssh command on your laptop/desktop, you'll be prompted for two ALCF authentication one-time passwords (Mobilepass+ or Cryptocard passcodes) - one for bastion, and the other for the Aurora login node. Likewise, when you run scp from a remote host to copy files to Aurora login nodes, you'll be prompted for two ALCF authentication one-time passwords.

File: ~/.ssh/config

    user <your_ALCF_username>


Host *
    DynamicForward 3142
    IdentityFile ~/.ssh/id_rsa
    user <your_ALCF_username>

Proxy Settings

export HTTP_PROXY=
export http_proxy=
export https_proxy=
git config --global http.proxy

Git with SSH protocol

The default SSH port 22 is blocked on Aurora; by default, this prevents communication with Git remotes that are SSH URLs such as:

git clone [user@]server:project.git

For a workaround for GitLab, GitHub, and Bitbucket, edit ~/.ssh/config to include:

     User git

     User git

     User git

     Port 443
     ProxyCommand /usr/bin/socat -,proxyport=3128

Your environment variable Proxy Settings must be set as above.

Using Non-Default SSH Key for GitHub

If you need to use something besides your default SSH key on Aurora for authentication to GitHub in conjunction with the SSH workaround, you may set

export GIT_SSH_COMMAND="ssh -i ~/.ssh/specialGitKey -F /dev/null"

where specialGitKey is the name of the private key in your .ssh subdirectory, for which you have uploaded the public key to GitHub.


Programming Environment Setup

Loading Intel OneAPI SDK + Aurora optimized MPICH

The modules are located in /soft/modulefiles  and are setup by default in user path. The default set of modules is deliberately kept to a minimum on Aurora.

If you do a module list  and don't see the oneapi module loaded, you can reset it to default by following the instructions below: 

uan-0001:~$ module purge
uan-0001:~$ module restore

Cray PE for GNU compilers, PALS, etc., are located in /opt/cray/pe/lmod/modulefiles/core. Module path should already be set in your user env.


If you would like to load explicitly the fabric/network stack after you modify the default SDK/UMD, please load append-deps/default at the end as,

uan-0001:~$ module load append-deps/default

Note, Cray-PALS modulefile should be loaded last as its important that the correct mpiexec from PALS is present as the default mpi. This can be confirmed with type -acommand as below

uan-0001:~$ type -a mpiexec

mpiexec is /opt/cray/pe/pals/1.2.4/bin/mpiexec

You can also use other modules thanks to spack (see Spack and E4S for details).

Note that the default set of modules is deliberately kept to a minimum on Aurora.

For example, for cmake and tmux:

uan-0001:~$ module load spack-pe-gcc 
uan-0001:~$ module load cmake
uan-0001:~$ module load tmux


For iprof (the module name is THAPI) :

uan-0001:~$ module load spack thapi

OpenMP Stack Size on the CPU

This is a note that the default stack size per CPU OpenMP thread with Intel OpenMP is 4MB. ( ). It can also be queried at runtime by running with OMP_DISPLAY_ENV=T set. If you see a segfault in a code which uses OpenMP CPU threads, you can try increasing the value in this environment variable.

GPU Validation Check

In some cases a workload might hang on the GPU, in such situations its possible to use the included gpu_check script (FLR in JLSE) thats setup when you load the runtime, to verify if all the GPUs are okay, kill any hung/running workloads on the GPU and if necessary reset the GPUs as well.

x1922c6s6b0n0:~$ gpu_check -rq 

Checking 6 GPUs  . . . . . . .

All 6 GPUs are okay!!!


Various ways to use MPI.

Aurora MPICH

Aurora MPICH is what will be the primary MPI on Aurora. It is jointly developed by Intel and Argonne. It allows GPU-aware communication.

You should have access to it with the default oneAPI module loaded. 

Use the associated compiler wrappers mpicxx, mpifort, mpicc, etc., as opposed to the Cray wrappers CC, ftn, cc. As always, the MPI compiler wrappers automatically link in MPI libraries when you use them to link your application.

Use mpiexec to invoke your binary, or a wrapper script around your. binary. You will generally need to use a wrapper script to control how MPI ranks are placed within and among GPUs. Variables set by the HPE PMIX system provide hooks to things like node counts and rank counts.

The following job script and wrapper script illustrate:

Example job script: jobscript.pbs

#PBS -l select=32:system=aurora,place=scatter
#PBS -A MyProjectAllocationName
#PBS -l walltime=01:00:00
#PBS -N 32NodeRunExample
#PBS -k doe
export TZ='/usr/share/zoneinfo/US/Central'
export OMP_PROC_BIND=spread
cd /path/to/my/run/directory
echo Jobid: $PBS_JOBID
echo Running on host `hostname`
echo Running on nodes `cat $PBS_NODEFILE`
NRANKS=12          # Number of MPI ranks per node
NDEPTH=16          # Number of hardware threads per rank, spacing between MPI ranks on a node
NTHREADS=$OMP_NUM_THREADS # Number of OMP threads per rank, given to OMP_NUM_THREADS


mpiexec -np ${NTOTRANKS} -ppn ${NRANKS} -d ${NDEPTH} --cpu-bind depth -envall /home/zippy/bin/ ./myBinaryName

Where  should be in your path and located in /soft/tools/mpi_wrapper_utils/ It will round-robin GPU tiles between ranks.

The example job script includes everything needed except the queue name, which will default accordingly. Invoke it using qsub

qsub jobscript.pbs


CrayMPI is the MPI provide by HPE which is a derivative of MPICH. It is optimized for Slingshot but provides no integration with Intel GPUs.

This is setup for CrayPE 22.10.

Check CPE Version

> ls -l /opt/cray/pe/cpe
total 0
drwxr-xr-x 2 root root 264 Jun  1 21:56 22.10
lrwxrwxrwx 1 root root   5 Jun  1 21:41 default -> 22.10

Building on UAN

Configure the modules to bring in support for CPE and expected PALS environment.

UAN Build

#If still using oneapi SDK

> module unload mpich
#Purge env if you want to use Cray PE GNU compilers
#module purge

> module load craype PrgEnv-gnu cray-pmi craype-network-ofi craype-x86-spr craype/2.7.17 cray-pals/1.2.9 cray-libpals/1.2.9 cray-mpich

You can use the Cray HPE wrappers to compile MPI code that is CPU-only.

CPU-only compile/link

> cc -o test test.c

> ldd test | grep mpi => /opt/cray/pe/lib64/ (0x00007ff2f3329000)

Building code that utilizes offload should use the Intel compiler suite otherwise linking with cc could result in SPIR-V code getting stripped from the binary.

Add the specific MPI compiler and linker flags to link within your Makefile and use the Intel compiler of choice.


CMPIFLAGS=-I/opt/cray/pe/mpich/8.1.20/ofi/gnu/9.1/include -I/opt/cray/pe/pmi/6.1.6/include 
CXXOMPFLAGS=-fiopenmp -fopenmp-targets=spir64
CXXSYCLFLAGS=-fsycl -fsycl-targets=spir64
CMPILIBFLAGS=-D__TARGET_LINUX__ -L/opt/cray/pe/mpich/8.1.20/ofi/gnu/9.1/lib -L/opt/cray/pe/pmi/6.1.6/lib -Wl,--as-needed,-lmpi_gnu_91,--no-as-needed -Wl,--as-needed,-lpmi,--no-as-needed -Wl,--as-needed,-lpmi2
TARGETS=mpi-omp mpi-sycl

all: $(TARGETS)

mpi-omp.o: mpi-omp.cpp

mpi-sycl.o: mpi-sycl.cpp

mpi-omp: mpi-omp.o

mpi-sycl: mpi-sycl.o

    rm -f *.o $(TARGETS)

Expected output

Build Output

> make

icpx -c -fiopenmp -fopenmp-targets=spir64 -I/opt/cray/pe/mpich/8.1.20/ofi/gnu/9.1/include -I/opt/cray/pe/pmi/6.1.6/include  mpi-omp.cpp
icpx -o mpi-omp mpi-omp.o -fiopenmp -fopenmp-targets=spir64 -D__TARGET_LINUX__ -L/opt/cray/pe/mpich/8.1.20/ofi/gnu/9.1/lib -L/opt/cray/pe/pmi/6.1.6/lib -Wl,--as-needed,-lmpi_gnu_91,--no-as-needed -Wl,--as-needed,-lpmi,--no-as-needed -Wl,--as-needed,-lpmi2
icpx -c -fsycl -fsycl-targets=spir64 -I/opt/cray/pe/mpich/8.1.20/ofi/gnu/9.1/include -I/opt/cray/pe/pmi/6.1.6/include  mpi-sycl.cpp
icpx -o mpi-sycl mpi-sycl.o -fsycl -fsycl-targets=spir64 -D__TARGET_LINUX__ -L/opt/cray/pe/mpich/8.1.20/ofi/gnu/9.1/lib -L/opt/cray/pe/pmi/6.1.6/lib -Wl,--as-needed,-lmpi_gnu_91,--no-as-needed -Wl,--as-needed,-lpmi,--no-as-needed -Wl,--as-needed,-lpmi2

Running on Compute Nodes

The job script must also set the appropriate modules. It must also set the path to find the correct libpals as an older version gets picked up by default regardless of module selection.

#PBS -A Aurora_deployment
#PBS -q workq
#PBS -l select=1
#PBS -l walltime=10:00
#PBS -l filesystems=home

ranks=$((PBS_NODES * rpn))

#If still using oneapi SDK
module unload mpich

#Purge env if you want to use Cray PE GNU compilers
#module purge
module load craype PrgEnv-gnu cray-pmi cray-pmi-lib craype-network-ofi craype-x86-spr craype/2.7.17 cray-pals/1.2.4 cray-libpals/1.2.4 cray-mpich
module list


mpiexec -n $ranks -ppn $rpn ./mpi-omp

Submit the job from the UAN

Job submission

> qsub ./

Output from the test cases

OMP Output

> mpiexec -n 6 -ppn 6 ./mpi-omp
hi from device 2 and rank 2
hi from device 0 and rank 0
hi from device 3 and rank 3
hi from device 4 and rank 4
hi from device 1 and rank 1
hi from device 5 and rank 5

SYCL Output

> > mpiexec -n 6 -ppn 6 ./mpi-sycl
World size: 6
Running on Intel(R) Graphics [0x0bd6]
Hello, World from 4 ! 
Running on Intel(R) Graphics [0x0bd6]
Hello, World from 3 ! 
Running on Intel(R) Graphics [0x0bd6]
Hello, World from 0 ! 
Running on Intel(R) Graphics [0x0bd6]
Hello, World from 1 ! 
Running on Intel(R) Graphics [0x0bd6]
Hello, World from 2 ! 
Running on Intel(R) Graphics [0x0bd6]
Hello, World from 5 !

The programs used to generate these outputs are mpi-omp.cpp and mpi-sycl.cpp.



#include <mpi.h>
#include <omp.h>
#include <stdio.h>

int main(int argc, char** argv) {
  // Initialize the MPI environment
  // Get the rank of the process
  int world_rank;
  MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);

#pragma omp target device( world_rank % omp_get_num_devices())
    printf( "hi from device %d and rank %d\n", omp_get_device_num(), world_rank );

  // Finalize the MPI environment. module load daos/base


#include <mpi.h>
#include <sycl/sycl.hpp>
#include <stdio.h>
#include <string.h>

int main(int argc, char** argv) {
  // Initialize the MPI environment

  // Get the rank of the process
  int world_rank;
  int world_size;
  MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
  MPI_Comm_size(MPI_COMM_WORLD, &world_size);
  char zemask[256];
  snprintf(zemask, sizeof(zemask), "ZE_AFFINITY_MASK=%d", world_rank % 6);

  if (world_rank == 0) std::cout << "World size: " << world_size << std::endl;
  sycl::queue Q(sycl::gpu_selector{});

  std::cout << "Running on "
            << Q.get_device().get_info<sycl::info::device::name>()
            << "\n";

  Q.submit([&](sycl::handler &cgh) {
    // Create a output stream
    sycl::stream sout(1024, 256, cgh);

    // Submit a unique task, using a lambda
    cgh.single_task([=]() {
      sout << "Hello, World from "  << world_rank << " ! " << sycl::endl;
    }); // End of the kernel function

  });   // End of the queue commands. The kernel is now submited


  // Finalize the MPI environment. MPI_Finalize();



There is one central build of kokkos in place now, with \{Serial,OpenMP,SYCL\} execution spaces, with AoT for PVC.

module use /soft/modulefiles

module load kokkos

will load it. If you're using cmake to build your Kokkos app, it's the usual drill. Otherwise, loading this module will set the KOKKOS_HOME environment variable, which you can use in Makefiles etc. to find include files and libraries.

Debugging Applications

Running gdb-oneapi in batch mode

In batch mode, gdb-oneapi can attach to each MPI ranks to obtain stack traces.  The standard output and error can go to individual files distinguished by environment variables PBS_JOBID and PALS_RANKID.  The example command below uses mpiexec to launch bash to access the environment variables of each MPI rank, and redirects their outputs.  The bash process calls gdb-oneapi, which launches ./the_executable with optional arguments.  The gdb commands "run" and "thread apply all bt" runs the executable and prints out backtrace when the application receives erroneous signals.  More gdb commands can go in with each prefixed by "-ex", such as setting break points or extra signal handlers.  Note that the command below follows the Bourne shell's quoting rule, such that the whole gdb-oneapi ... command is in single quotes, and the environment variables only get interpreted by the bash process launched by mpiexec.

mpiexec [mpiexec_args ...] bash -c '
    gdb-oneapi -batch
        -ex run
        -ex "thread apply all bt"
        --args ./the_executable [executable_args ...]
        >out.${PBS_JOBID%.*}.$PALS_RANKID 2>err.${PBS_JOBID%.*}.$PALS_RANKID'


source $IDPROOT/etc/profile.d/

Spack and E4S

Spack is a package manager used to manage HPC software environments.

The Extreme-Scale Scientific Software Stack (E4S) is a project of ECP which provides an open-source scientific software stack.

The ALCF provides Spack-managed software on Aurora via modules, including E4S deployments.

Using Spack packages

Currently, two Spack metamodules are available: spack-pe-gcc/0.4-rc1 and spack-pe-oneapi/0.4-rc1. Loading a metamodule will make additional software modules available:

uan-0001:~$ module load spack-pe-gcc

uan-0001:~$ module avail
--------------------- /soft/packaging/spack/gnu-ldpath/modules/linux-sles15-x86_64 ----------------------
 autoconf/2.69-gcc-11.2.0-mfogo75 ninja/1.11.1-gcc-11.2.0-6biwuw5
 autoconf/2.71-gcc-11.2.0-ofpl6wv (D) numactl/2.0.14-gcc-11.2.0-nzqw57c
 automake/1.15.1-gcc-11.2.0-2kuz3tx openssl/1.1.1d-gcc-11.2.0-amlvxob
 babeltrace2/2.0.4-gcc-11.2.0-xfjn3pn patchelf/0.17.0-gcc-11.2.0-rsf5nuy
 bzip2/1.0.6-gcc-11.2.0-gs35ttl perl/5.26.1-gcc-11.2.0-pqmes6b
 cmake/3.24.2-gcc-11.2.0-pcasswq pkg-config/0.29.2-gcc-11.2.0-cchn55a

uan-0001:~$ module load cmake
uan-0001:~$ which cmake

The spack module loads basic libraries and utilities, while the e4s modules load more specialized scientific software. Packages in the e4s modules are not optimized when installed; however, individual package builds may be customized by request to provide alternative variants or improve performance.

The available packages for each Spack deployment are listed at the bottom of this page.

Using Spack to build packages

You may find Spack useful for your own software builds, particularly if there is a large dependency tree associated with your software. In order to do so, you will need to install a user instance of Spack. We recommend using the latest develop branch of Spack since it includes some necessary patches for Aurora's environment. See Spack's Getting Started Guide for installation details.

You can also copy the Spack configuration files used for the E4S deployment - this may simplify the process of using the OneAPI compilers as well as any external libraries and dependencies. Copy the files in /soft/packaging/spack/settings/ into your spack installation at $spack/etc/spack to apply the configurations to all environments using your Spack instance.

Package lists

--------------------- /soft/packaging/spack/gnu-ldpath/modules/linux-sles15-x86_64 ----------------------

-------------------------------- /soft/packaging/spack/e4s/22.11/modules --------------------------------


Please refer to the JLSE testbed VTune documentation (Note that this page requires JLSE Aurora early hw/sw resource account for access).

Because of the two-step process to login to the Aurora login nodes, going first through the bastion nodes, the instructions for VTune Profiler as a Web Server should be augmented: On your desktop/laptop, where you initiate the ssh session for port forwarding to the vtune gui backend you have started on Aurora, you should make this addition into your ~/.ssh/config file:

Insert this into your ~/.ssh/config file

Host *
    DynamicForward 3142
    IdentityFile ~/.ssh/id_rsa

where you replace id_rsa with the name of your own private ssh key file. When you run the port-forwarding ssh command on your laptop/desktop, you'll be prompted for two ALCF authentication one-time passwords - one for bastion, and the other for the Aurora login node.


Users should submit a request as noted below to have their DAOS pool created. Once created, users may create and manage containers within the pool as they wish.  As this time, we ask users to avoid creating data using erasure encoding data protection. The current release of DAOS has an issue during rebuild of EC protected data. This will be resolved in the next DAOS release.


Note: When DAOS is upgraded to 2.4, the system will be reformatted which will lead to data loss. Any critical data should be backed up to $HOME. Notification will be provided before the update happens.

Using DAOS:

     Your pool will be named by the short name of your project. You will have permissions to create and manage containers within the pool.

  1. Request a storage allocation between 1 to 50TB for your project by emailing with the following information:
    • Aurora DAOS Pool
      • Username for owner 
      • Unix group for read/write access
      • Storage capacity
  2.  Load the daos/base module. (This should be a default module)
module load daos/base

module list
  1. Confirm access to pool


Pool Example

daos pool query <pool name>

harms@uan-0002:~> daos pool query software
Pool 050b20a3-3fcc-499b-a6cf-07d4b80b04fd, ntarget=640, disabled=0, leader=2, version=131
Pool space info:
- Target(VOS) count:640
- Storage tier 0 (SCM):
  Total size: 6.0 TB
  Free: 4.4 TB, min:6.5 GB, max:7.0 GB, mean:6.9 GB
- Storage tier 1 (NVMe):
  Total size: 200 TB
  Free: 194 TB, min:244 GB, max:308 GB, mean:303 GB
Rebuild done, 4 objs, 0 recs
  1. Create a container

     The container is your basic unit of storage. A POSIX container can contain 100s of millions of files, you can use it to store all of y our date. You only need a small set of containers perhaps just one per major unit of project work.


Container Example

mkcont --type POSIX --pool <pool name> --user $USER --group <group> <container name>

harms@uan-0002:~> mkcont --type=POSIX --pool iotest --user harms --group users random

  Container UUID : 9a6989d3-3835-4521-b9c6-ba1b10f3ec9c

  Container Label: random                              

  Container Type : POSIX                               

Successfully created container 9a6989d3-3835-4521-b9c6-ba1b10f3ec9c

  1. Mount the container

     Currently, you must manually mount your container prior to use on any node you are working on.

    For the UAN, mount it at a convenient mount point using the default dfuse parameters. This enables full caching or both metadata and data for best interactive performance.

Mount Example

dfuse --pool=<pool name> --cont=<cont name> -m $HOME/daos/<pool>/<cont>

mkdir -p $HOME/daos/iotest/random

dfuse --pool=iotest --cont=random -m $HOME/daos/iotest/random

harms@uan-0002:~> mount | grep iotest

dfuse on /home/harms/daos/iotest/random type fuse.daos (rw,nosuid,nodev,noatime,user_id=4211,group_id=100,default_permissions)

From a compute node (CN), you need to mount the container on all compute nodes. We provide some scripts to help perform this from within your job script.

More examples are available in /soft/daos/examples. The following examples uses two support scripts to startup dfuse on each compute node and then shut it down at job end.

Job Submission

qsub -v DAOS_POOL=<name>,DAOS_CONT=<name> ./

Job Script Example

#PBS -A <project>
#PBS -lselect=1
#PBS -lwalltime=30:00
#PBS -k doe
# Test case for MPI-IO code example
# ranks per node


# threads per rank

# nodes per job
nnodes=$(cat $PBS_NODEFILE | wc -l)

# Verify the pool and container are set
if [ -z "$DAOS_POOL" ];
    echo "You must set DAOS_POOL"
    exit 1
if [ -z "$DAOS_CONT" ];
    echo "You must set DAOS_CONT"
    exit 1

# load daos/base module (if not loaded)
module load daos/base
module unload mpich/50.1/icc-all-pmix-gpu
module use /soft/restricted/CNDA/updates/modulefiles
module load mpich/50.2-daos/icc-all-pmix-gpu

# print your module list (useful for debugging)
module list

# print your environment (useful for debugging)

# turn on output of what is executed
set -x

# clean previous mounts (just in case)

# launch dfuse on all compute nodes
# will be launched using pdsh
# arguments:
#   pool:container
# may list multiple pool:container arguments
# will be mounted at:
#   /tmp/<pool>/<container> ${DAOS_POOL}:${DAOS_CONT}

# change to submission directory

# run your job(s)
# these test cases assume 'testfile' is in the CWD
cd /tmp/${DAOS_POOL}/${DAOS_CONT}

echo "write"
mpiexec -np $((rpn*nnodes)) \
-ppn $rpn \
-d $threads \
--cpu-bind numa \
-genvall \

echo "read"
mpiexec -np $((rpn*nnodes)) \
-ppn $rpn \
-d $threads \
--cpu-bind numa \
-genvall \

# cleanup dfuse mounts ${DAOS_POOL}:${DAOS_CONT}

exit 0
  1. Usage

      Application can use POSIX codes as normal using a DAOS POSIX container. MPI-IO based codes can use the a DAOS MPICH ADIO by prepending the 'daos:' string to the path passed to MPI_File_open().

     Additional, improved performance can be had by using a special preloaded library. Adding LD_PRELOAD=$DAOS_PRELOAD into the mpiexec command will enable kernel bypass of most POSIX I/O calls, but still use metadata via the FUSE mount point.