Skip to main content

Software and system setup

Install Bases2Fastq™ as a static binary or Docker container and configure the compute environment.

When you set up Bases2Fastq on a system, you must install a static binary executable or use a Docker container. Additionally, to set up Docker or a static binary compute environment that meets system requirements, you must configure the compute environment to transfer files.

System requirements​

Operating system​

Bases2Fastq is compatible with various operating systems (OS). Review the following compatibility matrix to determine the appropriate Bases2Fastq distribution for your OS:

Operating SystemDocker CompatibilityStatic Binary CompatibilityOS Notes
Linux OSYes, Green CheckmarkYes, Green CheckmarkThe static binary executable is compatible with any Linux OS on an x86 architecture that uses glibc v2.19 or later.
To verify the glibc version for static binary, run the following command: ldd --version
Windows OSYes, Green CheckmarkNo, Red XWindows OS is not directly compatible with the static binary executable. Install Docker and run using Docker. Make sure to review the system requirements. Element Biosciences recommends enabling the WSL 2 backend feature.
Windows OS with Windows Subsystem for Linux (WSL)Yes, Green CheckmarkYes, Green CheckmarkIf you install WSL on Windows OS, you can use the static binary executable in the WSL environment.
Mac OSYes, Green CheckmarkNo, Red XMacOS is not compatible with the static binary executable. Install Docker and run using Docker.
Note:

Bases2Fastq is not supported on ARM processors.

Memory and performance for AVITI and AVITI24 sequencing​

Software performance is based on the resources that are dedicated to the processing environment. For optimal performance, make sure that you have at least 16 CPU cores available and enable threading Bases2Fastq with the -p argument. The following memory requirements apply to both Docker and static binary distributions:

  • A 2 x 75 or 2 x 150 AVITI System run requires 4 GB RAM per concurrent thread.
  • A 2 x 300 AVITI System run requires 6 GB RAM per concurrent thread.

The following benchmarks estimate the time Bases2Fastq takes to execute a 2 x 150 sequencing run:

SetupTime Estimate
A non-volatile memory express (NVMe) solid-state drive (SSD) that uses 8 threads60 minutes
An NVMe SSD that uses 20 threads30 minutes
An Amazon m5.12xlarge EC2 instance with 48 virtual CPUs and onboard SSD storage< 30 minutes

Memory and performance for Vitari sequencing​

Software performance is based on the resources that are dedicated to the processing environment. For optimal performance, make sure that you have at least 32 CPU cores available and enable threading Bases2Fastq with the -p argument. The following memory requirements apply to both Docker and static binary distributions for a 2 x 150 Vitari™ run:

  • Default processing requires about 20 GB of memory overhead plus 1 GB RAM per concurrent thread.
  • --unzip-to-disk requires about 1 GB RAM per concurrent thread.

--unzip-to-disk writes decompressed bases files to the temporary directory instead of holding them in memory. The option uses about 40 GB more temporary storage than default processing.

--unzip-to-disk increases runtime. The slowdown depends on disk throughput. With very high-throughput disks, runtime approaches default processing.

The following benchmarks estimate the time Bases2Fastq takes to execute a 2 x 150 Vitari sequencing run with default processing:

SetupTime Estimate
A non-volatile memory express (NVMe) solid-state drive (SSD) that uses 16 threads3.25 hours
An NVMe SSD that uses 32 threads2.5 hours
An NVMe SSD that uses 48 threads2.25 hours

Temporary directory​

When you use cloud storage, Bases2Fastq downloads input files and stages output files in a temporary directory. Intermediate files that are generated during analysis are also stored in the temporary directory. After an execution completes, the temporary directory is cleared.

The necessary amount of scratch space is based on the number of polonies and cycles in the run and the optional arguments in the Bases2Fastq execution.

By default, Bases2Fastq uses the temporary directory of the OS. To change the location of the temporary directory, set the environment variable TMPDIR. Use the following example command and replace /path/to/scratch with the desired directory:

Set TMPDIR in Linux env
export TMPDIR="/path/to/scratch"

AVITI and AVITI24 sequencing​

The temporary directory typically uses 400–500 GB for a 2 x 150 AVITI™ or AVITI24™ run (approximately 1 billion reads). For some applications, a run can use up to 800 GB.

Vitari sequencing​

The temporary directory typically uses 2.5–3.5 TB for a 2 x 150 Vitari run. Some runs can use up to 5 TB. --unzip-to-disk uses about 40 GB more temporary storage than default processing.

File transfer and storage setup​

To transfer files, Bases2Fastq requires paths to input and output locations. You can store input and output files in a local location or the cloud. For cloud storage, the following providers are compatible:

  • Amazon Simple Storage Service (Amazon S3)
  • Google Cloud Storage (GCS)
  • Any rclone-compatible provider

Amazon S3 and GCS storage connections require credential configuration for Bases2Fastq execution. For more information, see Execute with Amazon S3 and Execute with GCS.

Rclone requirements​

Rclone is a command-line program to manage files on cloud storage. Rclone provides the ability to mount any local, cloud, or virtual file system. Rclone allows Bases2Fastq to access many cloud storage providers. However, Element has not tested every available rclone provider.

To download and install rclone, follow the instructions at rclone.org/install. To communicate with your cloud storage, configure an rclone remote setup. For more information, see the provider-specific instructions at rclone.org/#providers.

Bases2Fastq installation​

To set up Bases2Fastq, use Docker or static binary. Current and previous versions are available for installation.

NOTE

The static binary executable for Bases2Fastq is only compatible with specific OS configurations. Before installation, review the OS requirements.

Install the current version​

  1. Follow the OS-specific instructions at docs.docker.com/get-docker/.

  2. To pull the latest version of the Bases2Fastq image from the Element public registry at DockerHub, run the following command:

    docker pull elembio/bases2fastq

  3. To confirm that Bases2Fastq is operational, run the following commands to display the software version and help content:

    docker run elembio/bases2fastq bases2fastq --version
    docker run elembio/bases2fastq bases2fastq --help

  4. To test the software, you can download simulated data and complete the Getting Started with Bases2Fastq tutorial.

Install a previous version​

Bases2Fastq follows the semantic versioning specification. All major, minor, and patch versions are available by tag for both the Docker and static binary.

  1. To review information for previous versions of Bases2Fastq, see Release Notes and Version Compatibility.

  2. To complete the instructions for Bases2Fastq installation use a command to download a previous version. See the following code examples:

# Get the latest of version 2
docker pull elembio/bases2fastq:2

# Get the latest minor 2.4 version
docker pull elembio/bases2fastq:2.4

# Get a specific major, minor, patch version
docker pull elembio/bases2fastq:2.4.0

Verifying Bases2Fastq binary via signature​

The Bases2Fastq binary is digitally signed by DigiCert to ensure security. The release tarball includes the signature file bases2fastq.sig alongside the bases2fastq binary. In the Docker image, the signature file is /usr/bin/bases2fastq.sig.

From the directory where you extracted the tarball, run the verification command with both the binary and the signature file.

openssl cms -verify -binary -inform DER -in bases2fastq.sig -content ./bases2fastq -CApath /etc/ssl/certs -purpose any > /dev/null && echo "OK: signature valid"

You should receive a response verifying the binary is the same image Element published.

OK: signature valid
Last updated on