1. CUDA Toolkit

The cryoSPARC worker node requires CUDA to be installed alongside an NVIDIA GPU. CUDA is a parallel computing platform and programming model developed by NVIDIA for general computing on its own GPUs.

CryoSPARC supports CUDA Toolkit version ≥9.2, ≤10.2 (11+ is not supported). You can install CUDA 9.2 from here.​

​Please note that newer GPUs require later versions of CUDA.​

2. Common Unix User Account

The cryoSPARC master and worker nodes must have the same Unix user available on each node.

Create a dedicated user account (e.g., cryosparcuser) that will run the cryoSPARC application on the master node and each worker node that will be used for computation.

In a master- worker setup, the cryoSPARC master node will use SSH to access the worker node and execute a bash script that will run the job a user has queued to that machine. Some lightweight job types queue directly to the master node, in which case the cryoSPARC master process will execute the job using a Python subprocess. If a user queues a job to a cluster, the cryoSPARC master process will submit a cluster job via the cluster workload scheduler's job submission system (for example via the sbatch command on a SLURM cluster).

For the purposes of this documentation, we will use the username cryosparcuser to represent the user that owns the cryoSPARC processes.

3. Password-less SSH Access

‌Set up SSH access between the master node and each standalone worker node. The cryosparcuser account should be able to SSH without a password (using a SSH key-pair) into all non-cluster worker nodes.

Setting up password-less SSH access to a remote workstation

Set up SSH keys for password-less access (only if you currently need to enter your password each time you ssh into the compute node).

If you do not already have SSH keys generated on your local machine, use ssh-keygen to do so.

Open a terminal prompt on your local machine, and enter:

ssh-keygen -t rsa -N "" -f $HOME/.ssh/id_rsa

Copy the RSA public key to the remote compute node for password-less login:

ssh-copy-id remote_username@remote_hostname

4. Open TCP Ports

Ensure ports 39000-39010 are accessible between every workstation node and the master node. The port range is configurable during install time. The following table details the purpose of each port.

Identifying open ports

To see what ports are being used on your master node, run the command netstat -tuplen. You can pipe the output to grep to search for specific ports. For example:

$ netstat -tuplen | grep :3900
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:39000           0.0.0.0:*               LISTEN      3002       2088014397  -
tcp        0      0 0.0.0.0:39001           0.0.0.0:*               LISTEN      3002       2088031342  -
tcp        0      0 0.0.0.0:39002           0.0.0.0:*               LISTEN      3002       2088039523  -
tcp        0      0 0.0.0.0:39003           0.0.0.0:*               LISTEN      3002       2088044546  -
tcp        0      0 0.0.0.0:39004           0.0.0.0:*               LISTEN      3002       2088021927  -
tcp        0      0 0.0.0.0:39005           0.0.0.0:*               LISTEN      3002       2088020880  -
tcp        0      0 0.0.0.0:39006           0.0.0.0:*               LISTEN      3002       2088022457  -‌

Testing open ports

To test if a TCP port is open (for example, to test if there is a firewall blocking the port), run a telnet command from another computer inside the network. If you see any response other than the one below (e.g., a timeout or a denial), it may indicate that the port is not listening or is blocked.

$ telnet cryosparc.server 39000
Trying 192.168.64.49...
Connected to cryoem5.slush.sandbox.
Escape character is '^]'.
$ ^C
Connection closed by foreign host.

5. Shared File System

The major requirement for installation is that all nodes (including the master) be able to access the same shared file system(s) at the same absolute path. These file systems (typically cluster file systems or NFS mounts) will be used for loading input raw data into jobs running on various nodes, as well as saving output data from jobs into projects.