📦 Project Spaces, Storage, and Available Software and Analysis Tools

Project Spaces

Project owners can request new projects using this form. To add additional team members to a project space, contact research@hbs.edu. Remember that you will not be able to request a project space or be added to an existing project until you have logged into the RCP at least once.

The landing page of the RCP displays tiles with all projects that you have access to:

Clicking on a project will bring you to the project workbench. The workbench displays active sessions on the top half of the page and available launchers, each corresponding to different analysis tools, on the bottom half of the page:

Storage

S3 Bucket

Each project has shared S3 storage available to all members of a project. This can be accessed by clicking on the "Files" tab to the right of the Workbench:

Please see our documentation about Transferring Files to learn more using this feature.

Database

The RCP offers database capabilities through a back-end connection to Amazon Aurora. Connection parameters, including the username, password, and hostname can be obtained by clicking on the "Service Credentials" box that appears in the upper right hand side of the Workbench. Clicking on the box will reveal the connection parameters:

Connecting to an Existing Database

See below for sample code to connect to your database using Python. If you prefer to use R, please contact RCS for customized instructions.

Python

Using the mysql python package:

import mysql.connector 
# Connect to the database 
conn = mysql.connector.connect( 
    user = 'username', 
    password = 'password'', 
    host = 'endpoint', 
    database = ''databasename')

DBeaver

DBeaver can be found on the Utility Launcher. After opening it, connect to an existing database by clicking on "Connect to a Database," select SQL, MySQL, and then Next.

Using the information in the Service Credentials found on the Workbench tab, paste the Endpoint into the Server Host box, and replace the Username and Password with your service credentials. Click on the + SSH, SSL, tab and select SSL.

Unclick verify server certificate and click Finish.

Creating a New Database

Database Naming Requirements

Your database name must start with a letter, and can only consist of letters, numbers, or underscores!

There are several ways to create a new database from a DataFrame, which may have been loaded from various file formats (such as CSV or Parquet). Below is sample Python code demonstrating one approach.

Python

Using the sqlalchemy python package:

from sqlalchemy import create_engine, text

# Define your Aurora cluster credentials and database name
AURORA_ENDPOINT = "endpoint" #The endpoint from the Service Credentials 
DB_USER = "username"
DB_PASSWORD = "password"
NEW_DB_NAME = "NewDatabase" #Database name of your choosing. Please note that the database name must start with a letter, and can only consist of letters, numbers, or underscores

try:
    # Create a SQLAlchemy engine
    engine = create_engine(f'mysql+pymysql://{DB_USER}:{DB_PASSWORD}@{AURORA_ENDPOINT}')

    # Create the database
    with engine.connect() as connection:
        connection.execute(text(f"CREATE DATABASE IF NOT EXISTS {NEW_DB_NAME}"))

    # Add the DataFrame to the database
    df.to_sql(name='my_table', con=engine, schema=NEW_DB_NAME, if_exists='replace', index=False)

except Exception as e:
    print(f"An error occurred: {e}")

Available software and analysis tools

The RCP launchers feature the most commonly used research software and analysis tools, including Rstudio, Spyder, VSCode, and Stata. Additionally, if applicable for the software, each launcher is preloaded with commonly used packages and modules.

Installing Packages or Modules

Important

Please note that the packages and modules you install are only available within a launcher, and not across the project's launchers. If you terminate the launcher, these packages and modules will be deleted.

If the package that you need to use is not preloaded, you can install it using the usual commands.

Installing R Packages

Using the standard command for install.packages() command from within RStudio will download and install the specified packages.

install.packages('somepkg')

Installing Python Modules

Python modules can be installed using the pip install command:

pip install some_module

To update/upgrade a module already installed, include also the --upgrade option:

pip install --upgrade some_module

Utility Launcher

The RCP features a Utility Launcher that makes it even easier to access commonly used desktop applications directly within your research environment. Use the Utility Launcher to quickly open tools such as:

LibreOffice for spreadsheets and documents
File and database browsers like DBeaver
Data transfer tools like FileZilla and rclone
Additional desktop applications, without any local installation or setup

To see all available applications, first, click on the oval button in the upper left-hand side of the screen:

Second, click on the app grid to reveal the installed applications:

Running Background Jobs

A background job lets you start a computation and walk away; it keeps running on the server even after you close your browser, and the results are waiting for you when you come back.

There are several ways to run background jobs on RCP, and selecting which to use depends on your use case. For small to medium jobs that can leverage the CPUs in a software's launcher for parallelization (if needed), you can run the background jobs in that launcher. For larger, more complex jobs that require a scheduler and/or extensive parallelization and resources, we recommend using the terminal provided in the Parallel Computing Services (PCS) launcher.

Research Software Launchers

Below, we provide detailed instructions and a video describing how to run long-running jobs in different launchers.

Jupyter

Overview

This guide explains two ways to run long-running Python jobs in the background using JupyterLab on the HBS Research Computing Platform (RCP).

Important: JupyterLab behaves differently from RStudio and VSCode. When you reconnect to a notebook after closing the tab, the notebook cells will appear idle (showing [ ] instead of [*]). This is misleading — the kernel IS still running in the background. Always verify using the terminal command described in Step 3 of Method 1.

Methods at a Glance

Method 1: Run Notebook & Close Tab	Method 2: Terminal with nohup
Run notebook cells, close the tab, and reconnect. The kernel continues running even though the notebook appears idle. Verify progress via the terminal.	Open a Terminal from the Launcher and use `nohup` to run a Python script fully detached. Best for: jobs where you want live monitoring and full stop/start control.

Method 1: Run in Notebook & Close the Tab

Step 1 — Open a New Notebook

In JupyterLab, click the + button or go to File > New Launcher. Under the Notebook section, click Python 3 (ipykernel) to create a new notebook.

Step 2 — Paste and Run the Script

In the first cell, paste your code. This example is called video_test.py:

import time
from datetime import datetime

with open("notebook_test.log", "w") as f:
    for i in range(60):
        msg = f"{datetime.now():%H:%M:%S} - Step {i+1} - still running"
        print(msg)
        f.write(msg + "\n")
        f.flush()
        time.sleep(5)

print("Done!")

Click the Run button (or press Shift+Enter) to execute the cell. You will see timestamped output appearing in the cell output area. The script also writes progress to a log file in your home directory.

Step 3 — Close the Browser Tab

While the cell is still running (shown by [*] next to it), close the JupyterLab browser tab. The kernel will continue executing in the background.

Step 4 — Reconnect and Verify

Return to the HBS RCP and click Connect on your JupyterLab session. Open your notebook. You may notice that the cell now shows [ ] (empty brackets) instead of [*] — this indicates that the notebook's display has disconnected from the kernel output.

The notebook appearing idle does NOT mean the job has stopped. The kernel continues running on the server.

To confirm the job is still running, open a new Terminal from the Launcher and run:

tail -f /your/home/directory/your_file_name.log

You should see new timestamped lines appearing, proving the notebook is still executing. Press Ctrl+C to stop watching the log.

Method 2: Terminal with nohup

Step 1 — Open a Terminal from the Launcher

In JupyterLab, open the Launcher (click the + button or File > New Launcher). Scroll down to the Other section and click the Terminal tile. A bash shell will open in a new tab.

Step 2 — Launch the Background Job

In the terminal, run:

nohup python your_file_name.py > output.log 2>&1 &

What each part means:

Part	Description
`nohup`	Keeps the job running after logout
`python your_file_name.py`	Runs your Python script
`> output.log`	Captures all printed output
`2>&1`	Also captures errors
`&`	Runs the process in the background

A process ID will appear (e.g., [1] 18079). Note this number. You can now close the browser tab — the job continues running.

Step 3 — Monitor Job Progress

tail -f output.log

New lines appear in real time. Press Ctrl+C to stop watching without stopping the job.

Step 4 — Check Whether the Job is Still Running

jobs

You will see:

[1]+  Running    nohup python your_file_name.py > output.log 2>&1 &

Stopping a Background Job

Run these commands in the JupyterLab terminal.

Method A — Kill by Job Number

kill 18079

Replace 18079 with the job number shown when you launched the job.

Method B — Kill by Process ID

kill %1

Method C — Kill by Script Name

pkill -f video_test.py

Best Practices

Test on a small sample before launching a full run.
Use log files to monitor progress and catch errors.
Remember: a notebook showing [ ] does not mean the job has stopped — always verify with tail -f.
Confirm your script writes files to the expected paths before starting.

Getting Help

If you run into any issues with background jobs or anything else on the RCP, the HBS Research Computing team is here to help.

📧 Email: research@hbs.edu

RStudio

Overview

This guide explains two ways to run long-running R jobs in the background using RStudio on the HBS Research Computing Platform (RCP).

Methods at a Glance

Method 1: Close the Browser Tab	Method 2: Terminal with nohup
Run your script in the RStudio console, then close the tab. The session keeps running. When you reconnect, your output will be waiting. Best for: simple scripts you want to kick off quickly.	Use RStudio's built-in Terminal with the `nohup` command to launch a script that runs fully detached from the browser session. Best for: long jobs where you want monitoring and control.

Method 1: Close the Browser Tab

Step 1 — Create and Save a Test Script

Open RStudio and create a new R script. This example script named video_test.R simulates a long-running analysis by printing a status message every 5 seconds for 60 iterations (5 minutes total).

for (i in 1:60) {
  print(paste("Step", i, "- still running"))
  Sys.sleep(5)
}
print("Done!")

Step 2 — Run the Script

With your script open, click the Run button in RStudio (or press Ctrl+Enter / Cmd+Enter) to execute the code. You will see output appearing in the Console panel:

[1] "Step 1 - still running"
[1] "Step 2 - still running"
...

Step 3 — Close the Browser Tab

Once the script is running, close the RStudio browser tab. The R session will continue running on the server in the background.

Step 4 — Reconnect and View Results

Navigate back to the HBS RCP and click Connect on your RStudio session. Scroll through the Console output to confirm the script continued running while the tab was closed.

Method 2: Terminal with nohup

Step 1 — Open the Terminal

In RStudio, click the Terminal tab at the bottom of the screen (next to the Console tab). A bash shell connected to the server will open.

Step 2 — Launch the Background Job

In the Terminal, run the following command and press Enter:

nohup Rscript your_file_name.R > output.log 2>&1 &

What each part means:

Part	Description
`nohup`	Keeps the job running after you log out or close the browser
`Rscript your_file_name.R`	Runs your R script from the command line
`> output.log`	Redirects all printed output to a log file
`2>&1`	Also captures error messages in the same log
`&`	Sends the process to the background immediately

After pressing Enter, a process ID (PID) and job number will appear, for example:

[1] 17942

This number is your job identifier. Note it down in case you need to stop the job later. You can now close the browser tab — the job will keep running.

Step 3 — Monitor Job Progress

To see the live output of your running job, reopen RStudio, go to the Terminal, and type:

tail -f output.log

New lines will appear in real time as Rscript runs. Press Ctrl+C to stop watching the log — this does NOT stop the job itself.

Step 4 — Check Whether the Job is Still Running

To verify the job is running in the background, type:

jobs

You will see output like:

[1]+  Running    nohup Rscript your_file_name.R > output.log 2>&1 &

Stopping a Background Job

If you discover a bug or need to cancel the job, there are three methods. All are run in the Terminal.

Method A — Kill by Job Number

kill 17942

Replace 17942 with the job number that was shown when you launched the job.

Method B — Kill by Process ID

kill %1

Method C — Kill by Script Name

pkill -f your_file_name.R

Useful if you have lost track of the job number or PID.

In all cases, confirm termination by running jobs again — you should see Terminated next to the job.

Best Practices

Test your script on a small sample before launching a full long-running job.
Validate that outputs look correct on a subset before scaling up.
Monitor output.log regularly with tail -f to catch errors early.
Confirm that your script writes output files to the expected paths before starting.
Save your script before running — unsaved edits will not be picked up.

Getting Help

If you run into any issues with background jobs or anything else on the RCP, the HBS Research Computing team is here to help.

📧 Email: research@hbs.edu

Stata

Overview

This guide explains two ways to run long-running Stata do-files in the background on the HBS Research Computing Platform (RCP).

Methods at a Glance

Method 1: Close the Browser Tab	Method 2: Terminal with nohup
Run your do-file from the Stata console, then close the browser tab. The session keeps running. Best for: quick kick-off with no extra commands.	Open a Terminal via the Stata desktop app grid and use `nohup stata -b do` to run the do-file fully detached. Best for: long jobs where you want monitoring and control.

Method 1: Close the Browser Tab

Step 1 — Create and Save a Test Do-File

Open Stata, create a new do-file, and paste your code inside. This example code called video_test.do displays a message every 5 seconds (5000 milliseconds) for 60 iterations.

forvalues i = 1/60 {
    display "Step `i' - still running"
    sleep 5000
}

Step 2 — Run the Do-File

You will see output appearing in the Results window:

Step 1 - still running
Step 2 - still running
...

Step 3 — Close the Browser Tab

While the do-file is still running, close the Stata browser tab. The Stata session will continue running on the server in the background.

Step 4 — Reconnect and View Results

Return to the HBS RCP and click Connect on your Stata session. The Results window will show output produced while the tab was closed.

Method 2: Terminal with nohup

Step 1 — Open Terminal

Stata on RCP runs inside a Linux desktop environment. To open a terminal, follow these two steps:

Click the oval/grid button in the top-left corner of the Stata desktop to open the application menu.
In the app grid, find and click the Terminal icon to open a bash shell window.

Step 2 — Launch the Background Job

In the terminal, run the following command and press Enter:

nohup stata -b do your_file_name.do > output.log 2>&1 &

What each part means:

Part	Description
`nohup`	Keeps the job running after logout or browser close
`stata -b do`	Runs Stata in batch (non-interactive) mode, executing a do-file
`your_file_name.do`	The do-file to run
`> output.log`	Redirects console output to a log file
`2>&1`	Also captures error messages
`&`	Runs the process in the background

A process ID and job number will appear (e.g., [1] 21449). Note this number. You can now close the browser tab — the job continues running.

Note: Stata batch mode also automatically creates a .log file matching your do-file name (e.g., video_test.log) in the current directory. This log captures the full Stata output including all displayed results.

Step 3 — Monitor Job Progress

To watch the live output from your Stata job, reopen the terminal and run:

tail -f your_file_name.log

New lines will appear in real time as Stata runs. Press Ctrl+C to stop watching the log — this does NOT stop the job itself.

Step 4 — Check Whether the Job is Still Running

jobs

You will see output like:

[1]+  Running    nohup stata -b do your_file_name.do > output.log 2>&1 &

Stopping a Background Job

Run these commands in the terminal. If you noted the process ID and job number previously, you can use the first two methods.

Method A — Kill by Job Number

kill 21449

Replace 21449 with the job number that was shown when you launched the job.

Method B — Kill by Process ID

kill %1

Method C — Kill by Do-File Name

pkill -f video_test.do

Useful if you have lost track of the job number or PID. Replace video_test.do with the name of your do-file.

In all cases, confirm termination by running jobs again — you should see Terminated next to the job.

Best Practices

Test your do-file on a small sample before launching a full long-running job.
Validate that outputs look correct on a subset before scaling up.
Monitor your log file with tail -f to catch errors early.
Confirm that your do-file writes datasets to the expected paths before starting.
Save your do-file before running — unsaved edits will not be picked up.

Getting Help

If you run into any issues with background jobs or anything else on the RCP, the HBS Research Computing team is here to help.

📧 Email: research@hbs.edu

VSCode

Overview

This guide explains two ways to run long-running Python jobs in the background using VSCode on the HBS Research Computing Platform (RCP).

Methods at a Glance

Method 1: Close the Browser Tab	Method 2: Terminal with nohup
Run your script using the VSCode play button, then close the tab. The session keeps running. Best for: quick kick-off with no extra commands.	Open a bash terminal in VSCode and use `nohup` to run the script fully detached. Best for: long jobs where you want monitoring and control.

Method 1: Close the Browser Tab

Step 1 — Create and Save a Test Script

Open VSCode and create a new file. This example code is called video_testing.py:

import time

for i in range(60):
    print(f"Step {i+1} - still running", flush=True)
    time.sleep(5)

print("Done!")

Step 2 — Run the Script

Click the play button (triangle) in the top-right corner of the editor. Output will appear in the Terminal panel at the bottom.

Step 3 — Stop an Interactive Job (if needed)

To stop a script that is currently running interactively, click the trash icon next to the Python terminal entry in the terminal panel.

Step 4 — Close the Browser Tab

Once the script is running, close the VSCode browser tab. The Python process continues on the server.

Step 5 — Reconnect and View Results

Return to the HBS RCP and click Connect on your VSCode session. The terminal will reconnect and show any output produced while you were away.

Method 2: Terminal with nohup

Step 1 — Open a Bash Terminal

The nohup command must be run in a bash terminal — not the Python terminal used for interactive runs. Click the + dropdown in the Terminal panel and select bash to open a new bash shell.

Step 2 — Launch the Background Job

In the bash terminal, run:

nohup python your_file_name.py > output.log 2>&1 &

What each part means:

Part	Description
`nohup`	Keeps the job running after logout
`python your_file_name.py`	Runs your Python script
`> output.log`	Redirects printed output to a log file
`2>&1`	Also captures errors in the same file
`&`	Sends the process to the background

A process number and job ID will appear (e.g., [1] 41386). Note this number. You can now close the browser — the job will continue running.

Step 3 — Monitor Job Progress

tail -f output.log

New lines appear in real time. Press Ctrl+C to stop watching without stopping the job.

Step 4 — Check Whether the Job is Still Running

jobs

You will see output like:

[1]+  Running    nohup python your_file_name.py > output.log 2>&1 &

Stopping a Background Job

Run these commands in the bash terminal.

Method A — Kill by Job Number

kill 41386

Replace 41386 with the PID shown when you launched the job.

Method B — Kill by Process ID

kill %1

Method C — Kill by Script Name

pkill -f your_file_name.py

Useful when you have lost track of the process ID or job number.

Best Practices

Test on a small sample before launching a full run.
Validate output on a subset before scaling up.
Monitor output.log regularly with tail -f.
Confirm your script writes files to the expected paths before starting.

Getting Help

If you run into any issues with background jobs or anything else on the RCP, the HBS Research Computing team is here to help.

📧 Email: research@hbs.edu

AWS Parallel Computing Service (PCS)

⚠️ Important: To use PCS, please ensure that the project owner has enabled the Private Networking and EFS services, and the PCS launcher. The first time you launch PCS, it will take about 15 minutes to provision.

AWS Parallel Computing Service (PCS) is a fully managed service that gives you access to a large compute cluster in the cloud. PCS allows you to submit computational jobs via submission scripts that can run across hundreds or thousands of CPUs simultaneously, dramatically reducing the time needed for large or complex analyses. You only pay for the computing time you use; AWS manages the underlying infrastructure.

Note: PCS uses SLURM submission scripts, whereas the HBSGrid uses an LSF scheduler. If you are moving from the HBSGrid to PCS, your batch submission scripts will need to be updated accordingly.

Accessing the PCS Launcher

Activate a PCS session and connect to it. Once the browser is connected, click on the oval in the upper left hand corner, select the app grid at the bottom of the screen, then open the Terminal:

Understanding PCS Storage Options

To take full advantage of the high-performance storage in the PCS launcher (EFS and Lustre), please copy or move relevant files (code/data) from your project space's S3 bucket to the PCS storage system (see instructions below). While you can technically work from files in your S3 bucket, you will not take advantage of the full power of the PCS system, and unexpected errors and job failures may occur as you cannot write streaming error or output files to the S3 bucket.

Note: the EFS and Lustre volumes are visible to all users in your project and persist across PCS sessions until you Terminate the launcher.

EFS: Recommended for single‑node, single‑stream work

For single-node, single-stream work, we recommend using the EFS volume. When you log into PCS and open a Terminal, your default working directory is on EFS. If you would like to create a new folder within it, you can use the mkdir <yourfolder> command.

cd /home/ec2-user/<yourfolder>

Lustre: Recommended for parallel, multi‑node work

For high‑throughput, multi‑node workloads, use the Lustre volume mounted at /shared. If you would like to create a new folder within it, you can use the mkdir <yourfolder> command.

cd /shared/<yourfolder>

Project Space (studies)

To facilitate copying or moving files from your project space's S3 bucket to EFS or Lustre, the studies folder (i.e., your project space folder) is visible from the PCS launcher here:

cd /mnt/studies/<yourprojectspacename>

Copying Files from S3 to PCS Storage

Below is sample code to copy a folder containing your relevant code/files from your project's S3 storage to the PCS storage system using the Terminal.

Note that using the -r flag ensures that all files inside the folder, including subfolders, are copied.

Copy to the EFS volume

cp -r /mnt/studies/<yourprojectspacename>/<folderwithfiles> /home/ec2-user/<yourfolder>

Copy to the Lustre volume

cp -r /mnt/studies/<yourprojectspacename>/<folderwithfiles> /shared/<yourfolder>

Running a Single-Node Job

Click to expand

1. Open the Terminal and navigate to your working folder

For single-node jobs, we recommend using the EFS volume under /home/ec2-user:

cd /home/ec2-user/<yourfolder>

2. Create a SLURM Job Script

The example below is a simple SLURM job script that runs on a single node and writes output and error files to the folder you are working from. Save the script below as job.sh in your working directory.

#!/bin/bash
#SBATCH -J single
#SBATCH -o single.%j.out
#SBATCH -e single.%j.err

echo "This is job ${SLURM_JOB_NAME} [${SLURM_JOB_ID}] running on ${SLURMD_NODENAME}, submitted from ${SLURM_SUBMIT_HOST}" && sleep 60 && echo "Job complete"

Below is a quick overview of the components of the bash script above; please see the SLURM documentation for additional detail.

Component	What It Is	What It Does
`#!/bin/bash`	Shebang line	Tells the system to run this script using the Bash shell — must always be the first line
`#SBATCH -J single`	SLURM directive	Sets the job name to `single` — this is what your job will be called in the queue
`#SBATCH -o` / `-e`	SLURM directive	Sets the output (`-o`) and error (`-e`) log files — `%j` is replaced with the job ID at runtime (e.g. `single.12345.out` / `single.12345.err`)
`echo ... && sleep 60 && echo "Job complete"`	Job body	Prints job details on start, waits 60 seconds to simulate work, then prints a completion message — `&&` ensures each command only runs if the previous one succeeded
`${SLURM_JOB_NAME}` `${SLURM_JOB_ID}` `${SLURMD_NODENAME}` `${SLURM_SUBMIT_HOST}`	SLURM variables	Automatically populated by SLURM at runtime — prints the job name, ID, compute node, and submit host inside the echo message

3. Determine the SLURM partition

In the Terminal, run this command to store the name of the partition you are working on. This command queries SLURM for the on-demand partition name and stores it in $PARTITION, which is used in the next step. The partition name can change between sessions, so this approach is preferred over hard-coding it in your script.

PARTITION=$(sinfo -h -o "%P" | grep ondemand | tr -d '*')

4. Submit the Job to SLURM

Submit the job script to the SLURM scheduler. SLURM will return a job ID.

sbatch --partition=$PARTITION job.sh

5. Monitor Job Status

Use the job ID returned by sbatch to monitor the job using the squeue command.

squeue --job <job-id>

Example:

squeue --job 1

Continue checking until the job reaches the R (running) state.

The job is complete when squeue no longer returns any output for the job ID.

6. Review Job Output Files

Once the job completes, inspect the contents of your folder to view the generated output and error files:

ls

View the contents of your output file:

cat single.<job-id>.out

It should read something similar to:

This is job single [1] running on awsPcs-7bce-od-1, submitted from ip-10-0-5-102.ec2.internal
Job complete

Running a Multi-Node Job

Click to expand

Note: This example uses the mpi4py package in Python, but you can run a similar multi-node job using other MPI wrappers (for example, MPI packages in R).

1. Open the Terminal and navigate to your working folder

For multi-node jobs, we recommend using the Lustre volume mounted on /shared:

cd /shared/<yourfolder>

2. Install the mpi4py package

In the Terminal:

pip install mpi4py

3. Create a Python MPI Script

Save the script below as hello_mpi.py in your working directory.

from mpi4py import MPI
import socket

comm = MPI.COMM_WORLD
rank = comm.Get_rank()
size = comm.Get_size()
hostname = socket.gethostname()

print(f"Hello from rank {rank} of {size} on {hostname}", flush=True)

all_hostnames = comm.gather(hostname, root=0)
if rank == 0:
    unique_nodes = set(all_hostnames)
    assert len(unique_nodes) > 1, f"FAILED — all ranks landed on the same node: {unique_nodes}"
    print(f"PASSED — job ran across {len(unique_nodes)} nodes: {unique_nodes}")

4. Create a SLURM Job Script

The example below requests two nodes and runs two MPI tasks per node (4 total tasks). It writes output and error logs to your current working directory. Save the script below as job.sh.

Note: Please ensure that you have included the IFACE code below. This detects the active network interface at runtime and directs MPI to use it for inter-node communication. Without it, MPI will not be able to communicate between nodes.

#!/bin/bash
#SBATCH -J multi
#SBATCH -o multi.%j.out
#SBATCH -e multi.%j.err
#SBATCH -N 2
#SBATCH --ntasks-per-node=2

IFACE=$(ip link show | awk '/state UP/ && !/LOOPBACK/{print $2}' | tr -d ':')
mpirun --mca btl_tcp_if_include $IFACE python3 hello_mpi.py

Below is a quick overview of the components of the bash script above; please see the SLURM documentation for additional detail.

Component	What It Is	What It Does
`#!/bin/bash`	Shebang line	Tells the system to run this script using the Bash shell — must always be the first line
`#SBATCH -J multi`	SLURM directive	Sets the job name to `multi`
`#SBATCH -o` / `-e`	SLURM directive	Sets the output (`-o`) and error (`-e`) log files — `%j` is replaced with the job ID at runtime (e.g. `multi.12345.out` / `multi.12345.err`)
`#SBATCH -N 2`	SLURM directive	Requests 2 compute nodes
`#SBATCH --ntasks-per-node=2`	SLURM directive	Launches 2 MPI tasks on each node — 4 tasks total across the 2 nodes
`IFACE=$(ip link show \| awk '/state UP/ && !/LOOPBACK/{print $2}' \| tr -d ':')`	Shell variable	Queries the active non-loopback network interface at runtime and stores it in `$IFACE` — preferred over hardcoding in case the interface name varies
`mpirun --mca btl_tcp_if_include $IFACE python3 hello_mpi.py`	Job body	Starts the MPI job restricted to the detected network interface and runs the Python script across all allocated tasks and nodes

5. Determine the SLURM partition

In the Terminal, run this command to store the name of the partition you are working on. This command queries SLURM for the on-demand partition name and stores it in $PARTITION, which is used in the next step. The partition name can change between sessions, so this approach is preferred over hard-coding it in your script.

PARTITION=$(sinfo -h -o "%P" | grep ondemand | tr -d '*')

6. Submit the Job to SLURM

Submit the job script to the SLURM scheduler. SLURM will return a job ID.

sbatch --partition=$PARTITION job.sh

7. Monitor Job Status

Use the job ID returned by sbatch to monitor the job using the squeue command.

squeue --job <job-id>

Example:

squeue --job 1

Continue checking until the job reaches the R (running) state. The job is complete when squeue no longer returns any output for the job ID.

8. Review Job Output Files

Once the job completes, inspect the contents of your folder to view the generated output and error files:

ls

View the contents of your output file:

cat multi.<job-id>.out

It should read something similar to:

Note: Because all 4 processes run in parallel, the order of the rank lines may vary between runs — this is normal. The PASSED line will always appear last.

Hello from rank 2 of 4 on ip-10-0-19-72.ec2.internal
Hello from rank 3 of 4 on ip-10-0-19-72.ec2.internal
Hello from rank 0 of 4 on ip-10-0-20-146.ec2.internal
Hello from rank 1 of 4 on ip-10-0-20-146.ec2.internal
PASSED — job ran across 2 nodes: {'ip-10-0-19-72.ec2.internal', 'ip-10-0-20-146.ec2.internal'}