Connecting/Logging in

All the connections to the Hoffman2 Cluster are based on a secure protocol that requires authentication. Currently we support the following ways to connect to the cluster:

• via terminal emulator and SSH client on your local machine

• via DCV remote desktop

• via Jupyter Notebook/Lab with h2jupynb

This page describes how to connect to the Hoffman2 Cluster, which runs the Slurm workload manager. To connect to the legacy cluster running the Altair Grid Engine (SGE), see Connecting/Logging in to the legacy cluster (Grid Engine). Remote desktops via NX or X2Go are available only on the legacy cluster; on the Slurm cluster use DCV instead.

As all connections are based on a secure protocol, when logging in for the first time, for security reasons, you will be asked to confirm the authenticity of the host you are connecting to by double checking the hostkey fingerprint.

Connecting via terminal and SSH

One of the most powerful ways to use the cluster is via a Unix shell, such as Bash, tcsh, or others. Unix shells are programs that provide an interface between the user and the operating system via the command-line shell prompt onto which the user types commands. A Unix shell is executed by a terminal program. Depending on the operating system of your computer, you have several choices for which terminal to use when connecting with the cluster.

LinuxMacWindows

On any Linux distribution, you can use the standard SSH-client generally installed with the OS and available via any terminal application.

Important

Once you have identified your terminal application open it and issue:

$ ssh login_id@hoffman2.oarc.ucla.edu

substitute login_id with your Hoffman2 Cluster user name.

See SSH customization to learn how to prevent SSH connections dropping and more.

Note

After connecting to the Hoffman2 Cluster you are on a login-type node on which only light editing and job submissions should occur, all intensive work should be performed under either a scheduler-requested interactive session on a compute node or as a scheduler-submitted batch job. Please see the Hoffman2 Cluster policy Role of login nodes.

Problems with the instructions on this section? Please send comments here.

Connecting for the first time

As all connections are based on a secure protocol, the first time you connect from a local computer to the Hoffman2 Cluster you will be prompted with a message similar to:

The authenticity of host 'hoffman2.oarc.ucla.edu (HOST IP)' can't be established.
ED25519 key fingerprint is SHA256:raMAmWNUC+jol5nXFlR3m9JoeNcICfGjn+9NXUaKmHg.
Are you sure you want to continue connecting (yes/no)?

Where HOST IP is the IP address of one of the Hoffman2 Cluster public hosts.

Warning

Only proceed to connect if the ED25519 key fingerprint displayed in the prompted message corresponds to one of the ED25519 fingerprints listed in the Hoffman2 Cluster Public hosts hostkey fingerprints section.

If the ED25519 fingerprint displayed by your SSH client does not match one of the ED25519 fingerprints for the Hoffman2 Cluster public hosts, when attempting to connect you will get a message similar to:

@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the ED25519 host key has just been changed.

in this case, do not continue authentication; instead, contact us here or by email at: support@idre.ucla.edu.

Public hosts hostkey fingerprints

The Hoffman2 Cluster has the following classes of public, or external facing, hosts that are used to connect to the cluster:

Class	Hostname
Login nodes	hoffman2.oarc.ucla.edu
DCV remote desktop	dcv1.hoffman2.oarc.ucla.edu

The public hosts have the following hostkey fingerprints:

Login nodes (hoffman2.oarc.ucla.edu):

ED25519 SHA256: raMAmWNUC+jol5nXFlR3m9JoeNcICfGjn+9NXUaKmHg
ED25519 MD5:    64:e4:4a:0e:02:e9:d7:c0:b9:b4:69:f1:57:65:a7:4c

DCV remote desktop (dcv1.hoffman2.oarc.ucla.edu):

ED25519 SHA256: Ys5xUjsAe1j4sLwWNmCBRMJS0cQbkWg7BdH5hOnElN0
ED25519 MD5:    c3:13:bb:44:a8:91:ad:61:c0:40:94:58:93:5f:12:15

Depending on the software package you use to connect to the cluster, the public key can be represented with either of the fingerprint hashes given above. Current OpenSSH clients (Linux, macOS, Windows) display the SHA256 form.

For the hostnames and fingerprints of the legacy cluster’s login, data transfer, NX and X2Go hosts, see Legacy cluster hostkey fingerprints.

Warning

If the fingerprint hash doesn’t match one listed above, do not continue authentication and contact us here or by email at: support@idre.ucla.edu.

Opening GUI applications

Some interactive applications (e.g., Matlab Desktop, Mathematica Notebooks, gnuplot, etc.) require the ability to open a graphical user interface (GUI) window and interact with it using your local display. Assuming that you have installed a local X Window System you can then update your SSH command to perform X11 Forwarding.

This section covers cases in which no direct rendering is required (and software rendering is performed instead).

LinuxMacWindows

On UNIX-like systems, an X Window System server is generally available and running with the default installation (or can be readily installed via the OS package manager). You can enable X11 Forwarding (that is the ability to visualize, on your local computer, GUI applications running remotely on the cluster) by adding the -X flag to the ssh command you use to connect to the cluster. To do so, type into your terminal window:

$ ssh -X login_id@hoffman2.oarc.ucla.edu

where login_id is replaced by your cluster user name. See SSH customization to learn how to modify your local $HOME/.ssh/config file in place of adding -X to your ssh command.

Note

After connecting to the Hoffman2 Cluster you are on a login-type node on which only light editing and job submissions should occur, all intensive work should be performed under either a scheduler-requested interactive session on a compute node or as a scheduler-submitted batch job. Please see the Hoffman2 Cluster policy Role of login nodes.

Problems with the instructions on this section? Please send comments here

SSH customization

Prevent SSH connection dropping

To help prevent idle SSH connections from dropping, you could add keepalive options to your SSH command:

$ ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5 login_id@hoffman2.oarc.ucla.edu

where login_id is replaced by your cluster user name.

For convenience we recommend setting the following entries in your ssh_config file or your local $HOME/.ssh/config (you may need to create such file):

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 5

X11 Forwarding

You can override the ssh default for all your sessions by creating (or adding to) a file named config in the $HOME/.ssh local directory on your computer and adding the options:

Host *
  ForwardX11Trusted yes
  ForwardX11 yes

Hoffman2 Cluster specific customization

To make customization specific to your account on the Hoffman2 Cluster, add to your local $HOME/.ssh/config file:

Host hoffman2
  HostName hoffman2.oarc.ucla.edu
  User substitute_your_H2_login_id_here
  ServerAliveInterval 30
  ServerAliveCountMax 5
  ForwardX11Trusted yes
  ForwardX11 yes

where substitute_your_H2_login_id_here is replaced by your cluster user name. After saving the file you can then log onto the cluster via:

$ ssh hoffman2

Problems with the instructions on this section? Please send comments here

Setting up SSH clients for Windows

Built-in OpenSSH client on Windows

Current Windows 10 and Windows 11 systems include an OpenSSH client that can be used from Windows Terminal, PowerShell, or Command Prompt. Open one of those terminals and connect to the Hoffman2 Cluster with:

$ ssh login_id@hoffman2.oarc.ucla.edu

where login_id is replaced by your Hoffman2 Cluster user name.

To connect to the legacy Grid Engine cluster, use the legacy login host hoffman2.idre.ucla.edu instead (see Connecting/Logging in to the legacy cluster (Grid Engine)).

This built-in client is the recommended first option for terminal-based SSH access. Use MobaXterm, Git Bash with an X server, Cygwin/X, or another X11-capable setup when you need to display GUI applications from the cluster on your Windows computer.

Instructions for MobaXterm

Download and install the MobaXterm Home Edition, either the Portable or Installer edition will work. To log into the Hoffman2 Cluster open MobaXterm and click on the Session button (the Sessions button is circled in green in MobaXterm application with the Sessions button circled in green.).

MobaXterm application with the Sessions button circled in green.

A new window will pop-up to allow you to choose a type of session. Choose SSH by clicking on the SSH button (upper left corner) and fill the Remote host field with the Hoffman2 Cluster address, that is:

hoffman2.oarc.ucla.edu

save the session by pressing the OK button.

MobaXterm application with the SSH session set for Hoffman2.

You can also create a new session type which you will use to transfer files back and from the cluster to your local machine, by selecting the Sessions button again and choosing SFTP as the session type and fill the Remote host field with the Hoffman2 Cluster data transfer node address, that is:

dtn.hoffman2.idre.ucla.edu

save the session by pressing the OK button.

To access the cluster double click on the save SSH session.

Problems with the instructions on this section? Please send comments here.

Instructions for Xming and Git Bash

Download and install Xming and Xming fonts following the installer instructions. Download and install Git Bash following the installer instructions.

Start Xming from the programs, open Git Bash from the Start Menu, at its shell prompt issue:

$ export DISPLAY=localhost:0

Connect to the Hoffman2 Cluster by typing:

$ ssh -XY login_id@hoffman2.oarc.ucla.edu

where login_id is replaced by your cluster user name.

Instructions for Cygwin users

• Install Cygwin (including the X11 packages) on your Windows system.

• Open a Cygwin terminal.

• Enter the command: startxwin. This starts the X11 server on your Windows computer.

• In the (graphical) window that pops up, use the command ssh -X login_id@hoffman2.oarc.ucla.edu where login_id is replaced by your cluster user name.

Problems with the instructions on this section? Please send comments here.

Instructions for Windows Subsystem for Linux

Windows Subsystem for Linux (WSL) lets you run a Linux environment on Windows. On current Windows 10 and Windows 11 systems, install WSL from PowerShell or Windows Terminal with:

PS> wsl --install

After installation, restart Windows if prompted, open the installed Linux distribution from the Start Menu, and use the Linux ssh command:

$ ssh login_id@hoffman2.oarc.ucla.edu

where login_id is replaced by your Hoffman2 Cluster user name. See Microsoft’s WSL installation documentation for current installation options and requirements.

Problems with the instructions on this section? Please send comments here.

Connecting via DCV remote desktop

Amazon DCV gives you a full Linux (GNOME) desktop running on the Hoffman2 Cluster, displayed on your local computer by the DCV Viewer. Graphical applications run on the cluster and only the pixels are sent to your computer, so a DCV desktop is generally more responsive than X11 forwarding over SSH. Your desktop session keeps running when you close the viewer, so you can disconnect and later reconnect to it, also from a different computer.

The DCV host is:

Class	Hostname	Port
DCV remote desktop	dcv1.hoffman2.oarc.ucla.edu	8443

Important

The DCV host is shared by all DCV users. As on the login nodes, do not run CPU or memory intensive work directly on the desktop: open a terminal on the desktop and run it on a compute node with Slurm (see Running applications from the DCV desktop).

DCV software on your local computer

• The DCV Viewer (client), available for Windows, macOS and Linux from the Amazon DCV download page (Clients section):

  LinuxMacWindows

  Download the .rpm (RHEL, Rocky, Alma, Fedora) or .deb (Ubuntu, Debian) package for your distribution and install it, e.g.:

  $ sudo dnf install ./nice-dcv-viewer-*.rpm      # RHEL/Rocky/Alma/Fedora
  $ sudo apt install ./nice-dcv-viewer_*.deb      # Ubuntu/Debian
  

  make sure that dcvviewer is on your PATH.

• An SSH client. On Windows 10 (version 1809 or later) and Windows 11 the built-in OpenSSH client is used. If it is missing, install it from Settings > System > Optional features > Add a feature > OpenSSH Client.

• The launcher script for your operating system from the H2C_launch_DCV repository (see Downloading the DCV launcher script).

Downloading the DCV launcher script

On a terminal open on your local computer (not connected to the Hoffman2 Cluster) issue:

Linux / macOS / WSL / Git BashWindows PowerShell

$ curl -O https://raw.githubusercontent.com/ucla-oarc-hpc/H2C_launch_DCV/master/h2c_launch_dcv.sh

Starting or reconnecting to a DCV session

Run the launcher script from a terminal on your local computer, substituting login_id with your Hoffman2 Cluster user name:

Linux / macOS / WSL / Git BashWindows PowerShell / Command Prompt

$ bash h2c_launch_dcv.sh -u login_id

The script:

1. checks that the DCV Viewer is installed on your computer (if it is not, it prints where to download it and exits)

2. connects to dcv1.hoffman2.oarc.ucla.edu with SSH (you are prompted for your Hoffman2 Cluster password)

3. looks for your DCV session, named login_id-dcv, and creates a new virtual session if you do not have one yet

4. writes a temporary connection file (without your password), opens the DCV Viewer with it and deletes the file a few seconds later

The DCV Viewer then asks for your user name and password a second time to log into the desktop.

Running the script again while your session is still running reconnects you to the same desktop, with all its windows and applications as you left them. To see the script options run bash h2c_launch_dcv.sh -h (or .\h2c_launch_dcv.cmd -Help on Windows).

Note

Certificate warning. The DCV server uses a self-signed TLS certificate, so the first time you connect the DCV Viewer warns that the server identity cannot be verified. Check that the certificate fingerprint shown by the viewer matches one of:

SHA1:   79:2F:35:46:80:BF:9D:D3:F4:A5:D6:61:26:3C:6E:A9:95:E8:66:05
SHA256: BE:D8:1F:89:2A:78:6B:78:A4:A2:4A:91:8E:F7:AD:53:BD:27:DE:DC:28:63:5B:29:1B:69:E3:FA:4C:22:D4:74

Depending on the viewer version, the fingerprint may be shown with dashes instead of colons (e.g. 79-2F-35-...).

and, if it does, choose Trust & Connect (or Always trust this server). If it does not match, do not connect and contact us here.

The first SSH connection to the DCV host also asks you to confirm its host key, see: Public hosts hostkey fingerprints.

Tip

You can also connect without the script: once your session exists, open the DCV Viewer, enter dcv1.hoffman2.oarc.ucla.edu:8443#login_id-dcv as the server and log in with your Hoffman2 Cluster user name and password.

Disconnecting and ending a DCV session

• Disconnect (the session keeps running): close the DCV Viewer window. Run the launcher script again to reconnect.

• End the session: log out from the desktop (top-right menu > Power Off / Log Out > Log Out). This closes all the applications running on the desktop. You can also end it from a terminal connected to the DCV host:

  $ ssh login_id@dcv1.hoffman2.oarc.ucla.edu dcv close-session login_id-dcv
  

Please end your session when you no longer need it, so that its resources are available to other users.

Running applications from the DCV desktop

After connecting you can open a terminal on the DCV desktop (Activities > Terminal).

Note

After connecting to the Hoffman2 Cluster via DCV you are on a login-type node on which only light editing and job submissions should occur, all intensive work should be performed under either a scheduler-requested interactive session on a compute node or as a scheduler-submitted batch job. Please see the Hoffman2 Cluster policy Role of login nodes.

To run a graphical application on a compute node and display it on your DCV desktop, start an interactive session with X11 forwarding by running the Hoffman2 Cluster script x11session, then start the application from it. For example, user joebruin could open MATLAB on a compute node with 4 cores and 16 GB of total memory for 3 hours with:

$ x11session --time=03:00:00 --cpus-per-task=4 --mem=16G
$ module load matlab
$ matlab &

See Slurm interactive sessions and Accounts, QOS and where your jobs run for how to request resources, and Requesting GPUs with Slurm for GPU nodes. Batch jobs can be submitted from the desktop with sbatch as from the login nodes (see Slurm batch jobs).

Problems with the instructions on this section? Please send comments here.

Jupyter Notebook/Lab with h2jupynb

The h2jupynb script starts a Jupyter Notebook or Jupyter Lab server on a compute node of the Hoffman2 Cluster and displays it in the web browser of your local computer. You run the script on your local computer; it:

1. connects with SSH to hoffman2.oarc.ucla.edu

2. starts a Slurm interactive session (srun) on a compute node with the resources you requested, and waits until it starts

3. loads the requested modules and environments and starts Jupyter on the compute node

4. opens an SSH tunnel from your computer to the notebook (the tunnel listens only on localhost of your computer)

5. opens the notebook in your default web browser

The session lasts for the runtime you requested (2 hours by default), or until you stop the script.

Warning

Run h2jupynb from a terminal open on your local computer, not on a terminal already connected to the Hoffman2 Cluster.

Getting the h2jupynb script

On your local computer you need:

• python 3 (the script also runs with python 2.6 or later). It is generally already installed on Linux and macOS; on Windows install it from Python.org (check Add Python to PATH), or with sudo apt-get install python3 in WSL.

• an SSH client (on Windows 10 and 11 the built-in OpenSSH client works from PowerShell, Command Prompt or Windows Terminal; Git Bash and WSL also work)

• a web browser

Download the Slurm version of the script, h2jupynb_slurm, saving it as h2jupynb, with a terminal open on your local computer:

Linux / macOS / WSL / Git BashWindows PowerShell

$ curl -o h2jupynb https://raw.githubusercontent.com/rdauria/jupyter-notebook/main/h2jupynb_slurm
$ chmod u+x h2jupynb

Note

This is a different script from the h2jupynb used on the legacy (Grid Engine) cluster, described in Connecting via Jupyter Notebook/Lab. If you keep both, save them under different names (e.g. h2jupynb and h2jupynb_ge). The Slurm version prints h2jupynb version 4.x when it starts.

To see the script options run:

$ python3 h2jupynb --help

Starting Jupyter with h2jupynb

To start a Jupyter Notebook with the default resources (1 CPU core, 5 GB of memory, 2 hours), user joebruin would issue:

$ python3 h2jupynb -u joebruin

substitute joebruin with your Hoffman2 Cluster user name (on Windows use python or py if python3 is not found).

The script prints the srun command that it will run, for example:

THE FOLLOWING INTERACTIVE SESSION WILL BE REQUESTED:

srun -J JUPYNB --time=2:00:00 --nodes=1 --ntasks=1 --cpus-per-task=1 --mem-per-cpu=5G --pty bash -c '...'

If the requested resources do not look correct, interrupt the script with Control-C. When the session starts, the script prints Running in Slurm job <JOBID> on <NODE>, and the notebook opens in your browser shortly after, with Succesfully opened notebook! printed on the terminal. A countdown shows the time left in the session.

Note

Password prompts. On Linux and macOS (and WSL), the script uses one SSH connection for the session and the tunnel, so you are asked for your Hoffman2 Cluster password once. On Windows, or with -n no, it opens a second SSH connection for the tunnel and asks for your password again.

If the notebook does not open by itself, copy the http://localhost:<PORT>/?token=... address printed by the script (httpcommand=) into your browser.

Jupyter Lab. The script starts Jupyter Notebook. To switch to Jupyter Lab, in your browser address bar replace /tree with /lab, e.g. http://localhost:9394/tree becomes http://localhost:9394/lab.

Ending an h2jupynb session

Save your work, then press Control-C in the terminal where the script runs. This closes the SSH connections and ends the Slurm job. On Windows, if Control-C does not stop the script during the countdown, press Control-Break (on some laptops Ctrl+Fn+B), or close the terminal window. Closing the browser tab does not end the session.

The session also ends when the requested runtime runs out: save your notebooks before then.

Requesting resources with h2jupynb

Main h2jupynb options

Option	Meaning	Default
-u <user name>	Your Hoffman2 Cluster user name	same as on your local computer
-t <hours>	Runtime in hours (at most 24, or 336 = 14 days with -q highp)	2
-m <GB>	Memory per CPU core, in GB	5
-s <cores>	Number of CPU cores, all on one node (with -e distributed: number of tasks)	1
-q highp	Use -q highp (or -o yes) to run on your group’s nodes; only for PI groups that have contributed nodes and whose nodes have already moved to the Slurm cluster. Otherwise leave it out: the session is routed automatically (see Accounts, QOS and where your jobs run).	routed automatically
-A <Slurm account>	Your group’s Slurm account, pi_<PI's user name> (e.g. pi_gobruin). This is not your user name, which goes with -u. Required if you belong to more than one Slurm account (see h2 whoami on the cluster).	your only Slurm account
-a <CPU type>	CPU type, e.g. intel-gold-6240; intel, intel-gold or amd for any CPU of that family	any
-x yes	Reserve a whole node for the session	no
-g yes	Run on a GPU node (one GPU) and load the cuda module	no
-c <GPU card>	GPU card: A100, K40m, P4, RTXPRO6000Bw (implies -g yes)	any
-r <GB>	GPU memory: 8, 12, 40, 97 (implies -g yes)	any
-l <version>	CUDA version (11.7 … 13.2)	12.8
-v <version>	Python version (3.10.20, 3.12.13), miniforge (for conda environments) or apptainer	3.12.13
-k <path>	Python virtual environment to activate
-j <name>	Conda environment to activate (with -v miniforge)
-f <file.sif>	Apptainer container to run Jupyter from (with -v apptainer)
-b <modules>	Comma separated list of modules to load, e.g. -b gsl/2.6,curl/7.70.0
-d <path>	Directory on the cluster in which Jupyter starts	$HOME
-p <port>	Port used by Jupyter and the tunnel	random, 6222–10000

Options that are not valid fall back to their defaults (the script prints a message). Detailed help for groups of options is available with --help_defaults, --help_cpu, --help_gpu, --help_python, --help_envs and --help_apptainer.

Examples (substitute joebruin with your user name):

• 5 hours, 10 GB of memory per core, on a node with any Intel Gold CPU:

  $ python3 h2jupynb -u joebruin -t 5 -m 10 -a intel-gold
  

• 4 cores (and 4 × 8 GB of memory) for 8 hours on your group’s nodes (-q highp, only if your PI group has contributed nodes that are already in the Slurm cluster). Here user joebruin (-u) belongs to more than one Slurm account and runs under the account of PI gobruin (-A pi_gobruin):

  $ python3 h2jupynb -u joebruin -q highp -A pi_gobruin -s 4 -m 8 -t 8
  

• an A100 GPU with CUDA 12.8:

  $ python3 h2jupynb -u joebruin -g yes -c A100 -l 12.8
  

  To see the GPU types and how many are free, run h2 gpus on the cluster. CUDA 12 and later do not support K40m cards (the script switches to 11.8), and CUDA 13 does not support P4 cards (it switches to 12.8).

• 16 tasks spread over 2 nodes, for parallel (e.g. MPI) work launched with srun from the notebook or its terminal:

  $ python3 h2jupynb -u joebruin -e distributed -s 16 -N 2 -m 4
  

  The notebook itself runs on the first node; srun commands run from it use all the tasks of the job.

Python environments and kernels with h2jupynb

Jupyter is installed in the python/3.12.13 module, which h2jupynb loads by default. With any other version of python, or to use your own packages, install Jupyter in your own environment. Do the installation in an interactive session on a compute node, not on a login node.

Python virtual environment (-k):

$ srun --time=1:00:00 --mem=4G --pty bash -l
$ module load python/3.12.13
$ python3 -m venv $HOME/.virtualenvs/myenv
$ $HOME/.virtualenvs/myenv/bin/pip install notebook numpy pandas

then start the notebook from your local computer with:

$ python3 h2jupynb -u joebruin -v 3.12.13 -k '$HOME/.virtualenvs/myenv'

Conda environment (-j), created with the miniforge module:

$ srun --time=1:00:00 --mem=4G --pty bash -l
$ module load miniforge
$ conda create -n myconda python=3.12 notebook numpy

then:

$ python3 h2jupynb -u joebruin -v miniforge -j myconda

The anaconda3 and mamba modules of the legacy cluster are not available on the Slurm cluster: -v anaconda3/... and -v mamba are changed to -v miniforge.

Apptainer container (-f): the container must have Jupyter installed; on GPU nodes it is started with --nv:

$ python3 h2jupynb -u joebruin -v apptainer -f '$HOME/containers/myjupyter.sif'

If Jupyter is not found in the environment you requested, the script prints JUPYTER NOT FOUND and exits.

Adding an environment as a kernel. Alternatively, keep using the default Jupyter of python/3.12.13 and register your environment as an additional kernel. Install ipykernel in the environment and, with the environment active, run:

$ python -m ipykernel install --user --name=myconda --display-name "My conda env"

the kernel My conda env then appears in the Jupyter launcher. GPU environments should be created on a GPU node (e.g. srun --gres=gpu:1 --time=1:00:00 --mem=8G --pty bash -l, then module load cuda/12.8).

The instructions on the legacy page for R kernels, the Bash kernel and Julia kernels also apply on the Slurm cluster; replace qrsh with an srun ... --pty bash -l interactive session and check the module versions with module avail.

To protect your notebook with a password, see Securing your Jupyter Sessions.

Troubleshooting h2jupynb

• “We seem to be on the wrong host!”: the Slurm session could not start. Read the srun error printed above the message. Common causes: you belong to more than one Slurm account and did not use -A; you passed your user name, instead of a Slurm account such as pi_gobruin, to -A (run h2 whoami on the cluster to see your Slurm accounts and QOS); or you requested -q highp but your PI group has no contributed nodes in the Slurm cluster yet.

• The script waits for a long time: the requested resources are not available yet (large memory, many cores, specific CPU or GPU types and whole nodes take longer). Interrupt with Control-C and request fewer resources, or check availability on the cluster with h2 gpus and sinfo -o "%20P %10c %10m %f".

• SSH problems: run the script with -z yes to write the SSH debug files myssh.log (and mytunnel.log) in the current directory, and attach them to your support ticket.

• No output in Git Bash: run python unbuffered, e.g. python -u h2jupynb -u joebruin.

When opening a ticket, include the full command you used and the output printed in your terminal.

Problems with the instructions on this section? Please send comments here.