CryoSPARC Guide
  • About CryoSPARC
  • Current Version
  • Licensing
    • Non-commercial license agreement
  • Setup, Configuration and Management
    • CryoSPARC Architecture and System Requirements
    • CryoSPARC Installation Prerequisites
    • How to Download, Install and Configure
      • Obtaining A License ID
      • Downloading and Installing CryoSPARC
      • CryoSPARC Cluster Integration Script Examples
      • Accessing the CryoSPARC User Interface
    • Deploying CryoSPARC on AWS
      • Performance Benchmarks
    • Using CryoSPARC with Cluster Management Software
    • Software Updates and Patches
    • Management and Monitoring
      • Environment variables
      • (Optional) Hosting CryoSPARC Through a Reverse Proxy
      • cryosparcm reference
      • cryosparcm cli reference
      • cryosparcw reference
    • Software System Guides
      • Guide: Updating to CryoSPARC v4
      • Guide: Installation Testing with cryosparcm test
      • Guide: Verify CryoSPARC Installation with the Extensive Validation Job (v4.3+)
      • Guide: Verify CryoSPARC Installation with the Extensive Workflow (≤v4.2)
      • Guide: Performance Benchmarking (v4.3+)
      • Guide: Download Error Reports
      • Guide: Maintenance Mode and Configurable User Facing Messages
      • Guide: User Management
      • Guide: Multi-user Unix Permissions and Data Access Control
      • Guide: Lane Assignments and Restrictions
      • Guide: Queuing Directly to a GPU
      • Guide: Priority Job Queuing
      • Guide: Configuring Custom Variables for Cluster Job Submission Scripts
      • Guide: SSD Particle Caching in CryoSPARC
      • Guide: Data Management in CryoSPARC (v4.0+)
      • Guide: Data Cleanup (v4.3+)
      • Guide: Reduce Database Size (v4.3+)
      • Guide: Data Management in CryoSPARC (≤v3.3)
      • Guide: CryoSPARC Live Session Data Management
      • Guide: Manipulating .cs Files Created By CryoSPARC
      • Guide: Migrating your CryoSPARC Instance
      • Guide: EMDB-friendly XML file for FSC plots
    • Troubleshooting
  • Application Guide (v4.0+)
    • A Tour of the CryoSPARC Interface
    • Browsing the CryoSPARC Instance
    • Projects, Workspaces and Live Sessions
    • Jobs
    • Job Views: Cards, Tree, and Table
    • Creating and Running Jobs
    • Low Level Results Interface
    • Filters and Sorting
    • View Options
    • Tags
    • Flat vs Hierarchical Navigation
    • File Browser
    • Blueprints
    • Workflows
    • Inspecting Data
    • Managing Jobs
    • Interactive Jobs
    • Upload Local Files
    • Managing Data
    • Downloading and Exporting Data
    • Instance Management
    • Admin Panel
  • Cryo-EM Foundations
    • Image Formation
      • Contrast in Cryo-EM
      • Waves as Vectors
      • Aliasing
  • Expectation Maximization in Cryo-EM
  • Processing Data in cryoSPARC
    • Get Started with CryoSPARC: Introductory Tutorial (v4.0+)
    • Tutorial Videos
    • All Job Types in CryoSPARC
      • Import
        • Job: Import Movies
        • Job: Import Micrographs
        • Job: Import Particle Stack
        • Job: Import 3D Volumes
        • Job: Import Templates
        • Job: Import Result Group
        • Job: Import Beam Shift
      • Motion Correction
        • Job: Patch Motion Correction
        • Job: Full-Frame Motion Correction
        • Job: Local Motion Correction
        • Job: MotionCor2 (Wrapper) (BETA)
        • Job: Reference Based Motion Correction (BETA)
      • CTF Estimation
        • Job: Patch CTF Estimation
        • Job: Patch CTF Extraction
        • Job: CTFFIND4 (Wrapper)
        • Job: Gctf (Wrapper) (Legacy)
      • Exposure Curation
        • Job: Micrograph Denoiser (BETA)
        • Job: Micrograph Junk Detector (BETA)
        • Interactive Job: Manually Curate Exposures
      • Particle Picking
        • Interactive Job: Manual Picker
        • Job: Blob Picker
        • Job: Template Picker
        • Job: Filament Tracer
        • Job: Blob Picker Tuner
        • Interactive Job: Inspect Particle Picks
        • Job: Create Templates
      • Extraction
        • Job: Extract from Micrographs
        • Job: Downsample Particles
        • Job: Restack Particles
      • Deep Picking
        • Guideline for Supervised Particle Picking using Deep Learning Models
        • Deep Network Particle Picker
          • T20S Proteasome: Deep Particle Picking Tutorial
          • Job: Deep Picker Train and Job: Deep Picker Inference
        • Topaz (Bepler, et al)
          • T20S Proteasome: Topaz Particle Picking Tutorial
          • T20S Proteasome: Topaz Micrograph Denoising Tutorial
          • Job: Topaz Train and Job: Topaz Cross Validation
          • Job: Topaz Extract
          • Job: Topaz Denoise
      • Particle Curation
        • Job: 2D Classification
        • Interactive Job: Select 2D Classes
        • Job: Reference Based Auto Select 2D (BETA)
        • Job: Reconstruct 2D Classes
        • Job: Rebalance 2D Classes
        • Job: Class Probability Filter (Legacy)
        • Job: Rebalance Orientations
        • Job: Subset Particles by Statistic
      • 3D Reconstruction
        • Job: Ab-Initio Reconstruction
      • 3D Refinement
        • Job: Homogeneous Refinement
        • Job: Heterogeneous Refinement
        • Job: Non-Uniform Refinement
        • Job: Homogeneous Reconstruction Only
        • Job: Heterogeneous Reconstruction Only
        • Job: Homogeneous Refinement (Legacy)
        • Job: Non-uniform Refinement (Legacy)
      • CTF Refinement
        • Job: Global CTF Refinement
        • Job: Local CTF Refinement
        • Job: Exposure Group Utilities
      • Conformational Variability
        • Job: 3D Variability
        • Job: 3D Variability Display
        • Job: 3D Classification
        • Job: Regroup 3D Classes
        • Job: Reference Based Auto Select 3D (BETA)
        • Job: 3D Flexible Refinement (3DFlex) (BETA)
      • Postprocessing
        • Job: Sharpening Tools
        • Job: DeepEMhancer (Wrapper)
        • Job: Validation (FSC)
        • Job: Local Resolution Estimation
        • Job: Local Filtering
        • Job: ResLog Analysis
        • Job: ThreeDFSC (Wrapper) (Legacy)
      • Local Refinement
        • Job: Local Refinement
        • Job: Particle Subtraction
        • Job: Local Refinement (Legacy)
      • Helical Reconstruction
        • Helical symmetry in CryoSPARC
        • Job: Helical Refinement
        • Job: Symmetry search utility
        • Job: Average Power Spectra
      • Utilities
        • Job: Exposure Sets Tool
        • Job: Exposure Tools
        • Job: Generate Micrograph Thumbnails
        • Job: Cache Particles on SSD
        • Job: Check for Corrupt Particles
        • Job: Particle Sets Tool
        • Job: Reassign Particles to Micrographs
        • Job: Remove Duplicate Particles
        • Job: Symmetry Expansion
        • Job: Volume Tools
        • Job: Volume Alignment Tools
        • Job: Align 3D maps
        • Job: Split Volumes Group
        • Job: Orientation Diagnostics
      • Simulations
        • Job: Simulate Data (GPU)
        • Job: Simulate Data (Legacy)
    • CryoSPARC Tools
    • Data Processing Tutorials
      • Case study: End-to-end processing of a ligand-bound GPCR (EMPIAR-10853)
      • Case Study: DkTx-bound TRPV1 (EMPIAR-10059)
      • Case Study: Pseudosymmetry in TRPV5 and Calmodulin (EMPIAR-10256)
      • Case Study: End-to-end processing of an inactive GPCR (EMPIAR-10668)
      • Case Study: End-to-end processing of encapsulated ferritin (EMPIAR-10716)
      • Case Study: Exploratory data processing by Oliver Clarke
      • Tutorial: Tips for Membrane Protein Structures
      • Tutorial: Common CryoSPARC Plots
      • Tutorial: Negative Stain Data
      • Tutorial: Phase Plate Data
      • Tutorial: EER File Support
      • Tutorial: EPU AFIS Beam Shift Import
      • Tutorial: Patch Motion and Patch CTF
      • Tutorial: Float16 Support
      • Tutorial: Particle Picking Calibration
      • Tutorial: Blob Picker Tuner
      • Tutorial: Helical Processing using EMPIAR-10031 (MAVS)
      • Tutorial: Maximum Box Sizes for Refinement
      • Tutorial: CTF Refinement
      • Tutorial: Ewald Sphere Correction
      • Tutorial: Symmetry Relaxation
      • Tutorial: Orientation Diagnostics
      • Tutorial: BILD files in CryoSPARC v4.4+
      • Tutorial: Mask Creation
      • Case Study: Yeast U4/U6.U5 tri-snRNP
      • Tutorial: 3D Classification
      • Tutorial: 3D Variability Analysis (Part One)
      • Tutorial: 3D Variability Analysis (Part Two)
      • Tutorial: 3D Flexible Refinement
        • Installing 3DFlex Dependencies (v4.1–v4.3)
      • Tutorial: 3D Flex Mesh Preparation
    • Webinar Recordings
  • Real-time processing in cryoSPARC Live
    • About CryoSPARC Live
    • Prerequisites and Compute Resources Setup
    • How to Access cryoSPARC Live
    • UI Overview
    • New Live Session: Start to Finish Guide
    • CryoSPARC Live Tutorial Videos
    • Live Jobs and Session-Level Functions
    • Performance Metrics
    • Managing a CryoSPARC Live Session from the CLI
    • FAQs and Troubleshooting
  • Guides for v3
    • v3 User Interface Guide
      • Dashboard
      • Project and Workspace Management
      • Create and Build Jobs
      • Queue Job, Inspect Job and Other Job Actions
      • View and Download Results
      • Job Relationships
      • Resource Manager
      • User Management
    • Tutorial: Job Builder
    • Get Started with CryoSPARC: Introductory Tutorial (v3)
    • Tutorial: Manually Curate Exposures (v3)
  • Resources
    • Questions and Support
Powered by GitBook
On this page
  • CryoSPARC System Architecture Overview
  • Master-worker pattern
  • Typical CryoSPARC System Setups
  • Single Workstation
  • Master-Worker
  • Clusters
  • CryoSPARC System Requirements
  • CryoSPARC Master Node Requirements
  • Worker Node/Cluster Worker Minimum Requirements
  • Operating System
  • Disks and compression
  • Solid State Storage (SSDs)
  • Graphical Processing Units (GPUs)
  • Browser Requirements
  • Additional Configuration Notes
  • Network Accessibility
  • Root Access
  • Multi-user environment
  • Deploying CryoSPARC on AWS
  • Database and Command API Security
  • Example Systems
  • Example Hardware Systems
  1. Setup, Configuration and Management

CryoSPARC Architecture and System Requirements

Description of CryoSPARC HPC software system architecture, typical setups (e.g., workstation, cluster).

PreviousNon-commercial license agreementNextCryoSPARC Installation Prerequisites

Last updated 2 months ago

CryoSPARC System Architecture Overview

CryoSPARC is a backend and frontend high-performance computing software system that provides data processing and image analysis capabilities for single particle cryo-EM, along with a rich browser-based user interface and command line tools.

CryoSPARC can be deployed on-premises or in the cloud.

CryoSPARC is designed to be run only within a trusted private network. CryoSPARC instances are not security-hardened against malicious actors on the network and should never be hosted directly on the internet or an untrusted network without a separate controlled authentication layer.

Master-worker pattern

The system is based on a master-worker pattern.

  • The master processes (web application, core application and MongoDB database) run together on one machine (master node). The master node requires relatively lightweight resources (4+ CPUs, 16GB+ RAM, 250GB+ HDD storage)

  • Worker processes run on any available/configured machine that has NVIDIA GPUs (worker node). The worker is responsible for all actual computation and data handling and is dispatched by the master node.

The same node can function as both master and worker.

The master-worker architecture allows CryoSPARC to be installed and scaled up flexibly on a variety of hardware, including a single workstation, groups of workstations, cluster nodes, HPC clusters, cloud nodes, and more.

Typical CryoSPARC System Setups

CryoSPARC can support a heterogeneous mixture of all typical setups in a single instance. This means you can start with installing CryoSPARC on a single workstation, then connect a worker node or cluster as your data processing requirements scale.

Single Workstation

Both the CryoSPARC master and CryoSPARC worker processes may run on the same machine. The only requirement is that GPU resources are available for the CryoSPARC worker processes. This is the simplest setup.

Master-Worker

1) All nodes have access to a shared file system. This file system is where the project directories are located, allowing all nodes to read and write intermediate results as jobs start and complete.

2) The master node has password-less SSH access to each of the worker nodes. SSH is used to execute jobs on the worker nodes from the master node.

3) All worker nodes have TCP access to 10 consecutive ports on the master node (default ports are 39000-39009). These ports are used for metadata communication via HTTP Remote Procedure Call (RPC) based API requests.

It is also possible to use one of the worker nodes as the master, in which case no standalone master node is necessary. Under high loads, this can lead to instability if the GPU worker node hangs or runs out of RAM, causing the master processes running the web application and database to also hang.

Clusters

1) All nodes have access to a shared file system. This file system is where the project directories are located, allowing all nodes to read and write results as jobs start and complete.

2) All worker nodes have TCP access to 10 consecutive ports on the master node (default ports are 39000-39009). These ports are used for metadata communication via HTTP Remote Procedure Call (RPC) based API requests.

For a cluster setup, the master node can be a regular cluster node (or even a login node) if this makes networking requirements easier, but the CryoSPARC master processes must be run continuously. If the master is to be run on a regular cluster node, the node may need to be requested from your scheduler in interactive mode or for an indefinitely running job.

Project directories are created in locations specified by CryoSPARC users. If administering a multi-user cluster instance, ensure that users create project directories in locations where both the master and worker nodes have access.

Supported cluster schedulers

CryoSPARC supports most cluster schedulers, including SLURM, SGE and PBS. Please see here for example cluster configurations for popular schedulers.

CryoSPARC System Requirements

The following are requirements for every master and worker node in the system unless otherwise specified.

Component
Requirement

Architecture

x86-64 (Intel or AMD)

Operating System

Shell

User Account

cryosparcuser

Software

Filesystem

Shared file system across all nodes

CryoSPARC Master Node Requirements

The following are requirements specific to the master node.

Component

Minimum Requirement

Recommended

CPU

4+ cores

8+ cores at 2.8GHz+

RAM

16GB+

32GB DDR4

System Storage

250GB+ HDD

500GB SSD

Fast Local Storage

Not Required

Not Required

GPU

Not Required

Not Required

Network

1Gbps link to storage servers

10Gbps link to storage servers

A 10Gbps connection is recommended to the storage servers given raw cryo-EM movies can be several TB in size, and I/O bottlenecks are more of a concern than processing power for pre-processing jobs in CryoSPARC.

Although a CPU with a higher core count is recommended, a CPU with a faster clock rate is more advantageous due to how master processes are implemented.

Enough System Storage is required to host the cryosparc_master installation package and database folder. Each CryoSPARC project occupies between 100MB and 5GB of database storage, depending on the size of the project. 500GB is enough for approximately 200 medium-sized projects. Note that this excludes the space required for CryoSPARC project data in bulk storage, which could be in terabytes for larger projects.

Worker Node/Cluster Worker Minimum Requirements

The following are requirements for each worker node/cluster worker.

Component

Minimum Requirement

Recommended

CPU

2+ cores per GPU

4 cores per GPU

CPU Memory Bandwidth

50+ GB/s

100+ GB/s

RAM

32GB+ per GPU

64GB DDR4 per GPU

System Storage

25GB+ HDD

50GB+ SSD

Fast Local Storage

1TB SSD

2TB PCIe SSD

GPU

1+ NVIDIA Tesla V100, RTX2080Ti, RTX3090, etc

Network

1Gbps link to storage servers

10Gbps link to storage servers

System RAM is very important for worker nodes and should scale proportionately to the number of GPUs available for processing on the system.

Enough System Storage is required to host the cryosparc_worker installation package.

Operating System

Disks and compression

Fast disks are a necessity for processing cryo-EM data efficiently. Fast sequential read/write throughput is needed during pre-processing stages (e.g., motion correction) where the volume of data is very large (tens of TB) while the amount of computation is relatively low (sequential processing for motion correction, CTF estimation, particle picking, etc.)

Spinning disk arrays in a RAID configuration are used to store large raw data files, and often cluster file systems are used for larger systems. As a rule of thumb, to saturate a 4-GPU machine during pre-processing, a sustained sequential read of 1000MB/s is required.

Compression can greatly reduce the amount of data stored in movie files, and also greatly speeds up preprocessing because decompression is actually faster than reading uncompressed data straight from disk. Typically, counting-mode movie files are stored in LZW compressed TIFF format without gain correction, so that the gain reference file is stored separately and must be applied on-the-fly during processing (which is supported by CryoSPARC). Compressing gain corrected movies can often result in much worse compression ratios than compressing pre-gain corrected (integer count) data.

CryoSPARC supports LZW compressed TIFF format, EER format and BZ2 compressed MRC format natively. In either case, the gain reference must be supplied as an MRC file. TIFF, EER and BZ2 compression are implemented as multi-core decompression streams on-the-fly.

Solid State Storage (SSDs)

SSD space is optional on a per-worker node basis but is highly recommended for worker nodes that will be running refinements and reconstructions using particle images. Nodes reserved for pre-processing (motion correction, particle picking, CTF estimation, etc) do not need to have an SSD.

CryoSPARC particle processing algorithms rely on random-access patterns and multiple passes through the data, rather than sequentially reading the data at once. Using a storage medium that allows for fast random reads will speed up processing dramatically.

The size of your typical single particle cryo-EM datasets will inform the size of SSD you choose to use. For a sample calculation, see:

Graphical Processing Units (GPUs)

At least one worker node must have GPUs available to run the complete set of CryoSPARC jobs. Non-GPU workers may run CPU-only jobs.

The GPU memory (VRAM) in each GPU limits the maximum particle box size for reconstruction. Typically, a GPU with 12GB VRAM can handle a box size of up to 700^3, and up to 1024^3 in some job types. See the following tutorial for more details.

Selecting GPUs

When acquiring GPUs to use with CryoSPARC, the following considerations may be useful.

  • CryoSPARC almost exclusively uses single-precision operations on the GPU. As such, consumer cards generally have a much better price/performance ratio than enterprise cards. Enterprise cards do have their own benefits such as reliability, better cooling for servers, longer support timelines, and compatibility with other applications that may use double-precision math.

  • The most important metric of a GPU is the device VRAM memory bandwidth. This is the rate at which the GPU can read and write from its own memory. This is generally more important than GPU core count or clock speed, as almost all operations on the GPU are memory-bandwidth limited. When selecting GPUs, this is the primary metric to compare (along with price). For example, the NVIDIA RTX 3090 has 24GB of memory at 936 GB/s bandwidth, the NVIDIA A100 has up to 80GB memory at 1935 GB/s bandwidth, and the NVIDIA A4000 has 16GB at 448 GB/s.

  • GPU memory size is the main limiting factor in terms of the box-sizes that can be handled during a 3D refinement. Other than this, memory size does not have any impact on speed. 11GB consumer cards can generally handle all processing steps (including motion correction of K3 data, etc) for particle box sizes up to 600^3.

  • GPU-CPU interconnect bandwidth (eg. PCIE) is generally not a bottleneck (e.g., for most job types, we get similar benchmark performance on 8x or 16x PCIE lanes) but IO bandwidth reading data from cluster storage/local SSD is usually a significant factor in performance. This is especially true for preprocessing and CryoSPARC Live, as movies, micrographs, and particles need to be read, written, and transferred rapidly to keep up with collection and GPUs can process the data very quickly.

  • In many cases, older or slower GPUs can often perform almost equally as well as the newest, fastest GPUs because most computations in CryoSPARC are not bottlenecked by GPU compute speed, but rather by GPU memory bandwidth and disk I/O speed.

Browser Requirements

Additional Configuration Notes

Network Accessibility

Network security must be an important factor in the installation and ongoing management of any CryoSPARC instance. Access to the network that hosts a CryoSPARC instance must be carefully controlled, as CryoSPARC instances are not security-hardened against malicious actors on the network.

CryoSPARC is designed to be run only within a trusted private network. CryoSPARC instances should never be directly hosted on the internet or an untrusted network, without a separate controlled authentication layer.

CryoSPARC’s User Interface does include a user management system, and CryoSPARC user accounts and passwords help control access to the interface within a trusted private network, but please note that CryoSPARC passwords are not intended as a barrier against malicious access.

Root Access

The CryoSPARC system is specifically designed not to require root access to install or use. The reason for this is to avoid security vulnerabilities that can occur when a network application (web interface, database, etc.,) is hosted as the root user. For this reason, the CryoSPARC system must be installed and run as a regular UNIX user (cryosparcuser), and all input and output file locations must be readable and writable as this user. In particular, this means that project input and output directories that are stored within a regular user's home directory need to be accessible by cryosparcuser, or else (more commonly) another location on a shared file system must be used for CryoSPARC project directories.

Multi-user environment

If you are installing the CryoSPARC system for use by many users (for example within a lab), there are two options:

Using UNIX Groups

Create a new regular user (cryosparcuser) and install and run CryoSPARC as this user. Create a CryoSPARC project directory (on a shared file system) where project data will be stored, and create sub-directories for each lab member. If extra security is necessary, use UNIX group privileges to make each sub-directory read/writeable only by cryosparcuser and the appropriate lab member's UNIX account. Within the CryoSPARC command-line interface, create a CryoSPARC user account for each lab member, and have each lab member create their projects within their respective project directories. This method relies on the CryoSPARC web application for security to limit each user to see only their own projects. This is not guaranteed security, and malicious users who try hard enough will be able to modify the system to be able to see the projects and results of other users.

Using Separate CryoSPARC Instances

If each user must be guaranteed complete isolation and security of their projects, each user must install CryoSPARC independently within their own home directories. Projects can be kept private within user home directories as well, using UNIX permissions. Multiple single-user CryoSPARC master processes can be run on the same master node, and they can all submit jobs to the same cluster scheduler system. This method relies on the UNIX system for security and is more tedious to manage but provides stronger access restrictions. Each user will need to have their own CryoSPARC license ID in this case.

Deploying CryoSPARC on AWS

CryoSPARC can be deployed on-premises or in the cloud. See below for a guide on deploying CryoSPARC on AWS resources.

Database and Command API Security

CryoSPARC is designed to run within a trusted private network. CryoSPARC instances are not security-hardened against malicious actors on the network and should never be exposed to the Internet or hosted on an untrusted network.

The information in this section, Database and Command API Security, applies to CryoSPARC v4.0+.

CryoSPARC v4.0 introduces additional authentication to reduce the likelihood of accidental mis-use by actors on a large institution/multi-user shared network.

Database Security

CryoSPARC's MongoDB database runs with access control enabled: Requests to read or write from the database must be authenticated with a username and password. CryoSPARC sets this password automatically and uses it for internal master → master and worker → master requests. Note that communication between the database and other CryoSPARC services is not encrypted.

Enable or disable MongoDB access control by setting CRYOSPARC_DB_ENABLE_AUTH variable in cryosparc_master/config.sh and cryosparc_worker/config.sh to true(default) or false.

To connect to the database with access control, use cryosparcm mongo to access the Mongo shell, or use cryosparcm icli to access an interactive Python client.

Command API Security

CryoSPARC's command server (executes actions triggered by the web application including creating and modifying projects and jobs) also requires authentication.

The command server expects the CryoSPARC License ID in theLicense-ID header of incoming web requests. CryoSPARC includes this automatically in internal requests to the API. Requests with missing or incorrect license ID will be rejected. Note that communication between the command server and other CryoSPARC services is not encrypted.

You provide the License ID during CryoSPARC master and worker package installation. The license is written in plain-text to config.sh in the installation directories. The license ID in the worker installation must match the master installation.

Optional password argument

CryoSPARC allows creating users and updating users from the command line. Rather than specifying a --password flag during these operations, you may omit it to instead run a secure password prompt.

Example Systems

We do not currently partner with any specific hardware vendors to sell machines with CryoSPARC pre-installed.

Example Hardware Systems

Below are details of example workstations that meet or exceed the minimum requirements specified above, including those we use internally for development and testing.

Component

Hardware Product

CPU

32 Cores (base clock 2.8GHz+), e.g, AMD Threadripper 3975X

Memory

256GB DDR4 @ 3200MHz

Storage

4TB PCIe SSD (cache); 200TB RAID 6 storage server via 10Gbps link (raw movies)

GPU

4x NVIDIA Quadro GV100, or 4x NVIDIA Tesla V100 or 4x NVIDIA RTX 8000

Component

Hardware Product

CPU

16 Cores (base clock 3.0GHz+)

Memory

128GB DDR4

Storage

2TB PCIe SSD (cache); HDD storage server in RAID configuration (raw movies)

GPU

2x NVIDIA RTX 3090

In the master-worker setup, the CryoSPARC master is installed on a lightweight machine, and the worker processes are installed on one or more GPU servers. This is the most flexible setup for installing CryoSPARC. There are three main requirements for this setup, which are also explained in greater detail in the :

The master node can also spawn or submit jobs to a cluster scheduler system (e.g., ). This integration is transparent, and works similar to the master-worker setup explained above, except all resource scheduling is handled by the cluster scheduler, and CryoSPARC's scheduler is only used for orchestration and management of jobs. Similar requirements are present:

Modern Linux OS ( is recommended). Please see the section on for more details and limitations.

Nvidia driver (worker nodes only). .

1+ NVIDIA GPU with , 11GB+ VRAM

High CPU memory bandwidth is especially important for .

Fast local storage is also necessary as reconstruction jobs require random access to particle images. SSDs provide high throughput in this context. See the section on for more details.

Currently, is the best operating system to use with CryoSPARC, as extensive testing is carried out on this platform before every release. Ubuntu 22.04 is not supported in CryoSPARC v3.4.0 and earlier, but is supported in CryoSPARC v4.0.0 and later.

There are various unresolved incompatibilities and instabilities when using CUDA applications on older Linux kernels (e.g., 3.10 found in CentOS 7). Several users have reported sporadic occurrences of and errors while using CentOS 7.

CryoSPARC manages the SSD cache on each worker node transparently. Files are automatically cached, re-used across the same project and deleted if more space is needed.

Please ensure each connected worker includes a recent version of the Nvidia Driver compatible with your GPU. See for details. . Visit to resolve common GPU errors.

The CryoSPARC web interface works best on the latest version of . and are also an option, although some features may not work as intended. Internet Explorer is not supported. for more information on accessing the CryoSPARC web interface.

installation sections of this document
Slurm Workload Manager
CryoSPARC Cluster Integration Script Examples
Solid State Storage
Ubuntu Desktop 16+
cufftInvalidPlan
cuMemHostAlloc Failed
Please see the SSD Caching guide for more information.
Tutorial: Maximum Box Sizes for Refinement
Google Chrome
Firefox
Safari
See this guide
Deploying CryoSPARC on AWS
Ubuntu
Operating System
Bash
CC 3.5+
Download the latest driver for your GPUs here
CryoSPARC Live preprocessing
LogoGuide: SSD Particle Caching in CryoSPARCCryoSPARC Guide
See details on Nvidia and CUDA requirements
this section
Troubleshooting
Core components included in the CryoSPARC system
Single CryoSPARC workstation example, where the master and worker processes run on a single machine.
Single-master, multiple-worker example. All nodes must have access to a shared file system.
CryoSPARC cluster integration example where both nodes have access to a shared file system