snakemake-workflows/rna-seq-xengsort

A standardized Snakemake workflow to separate host and graft sequencing reads from RNAseq data using xengsort.

Overview

Latest release: v1.0.0, Last update: 2026-07-17

Share link: https://snakemake.github.io/snakemake-workflow-catalog?wf=snakemake-workflows/rna-seq-xengsort

Quality control: linting: passed formatting: passed

Wrappers: bio/fastp bio/reference/ensembl-sequence

Deployment

Step 1: Install Snakemake and Snakedeploy

Snakemake and Snakedeploy are best installed via the Conda package manager. It is recommended to install conda via Miniforge. Run

conda create -c conda-forge -c bioconda -c nodefaults --name snakemake snakemake snakedeploy

to install both Snakemake and Snakedeploy in an isolated environment. For all following commands ensure that this environment is activated via

conda activate snakemake

For other installation methods, refer to the Snakemake and Snakedeploy documentation.

Step 2: Deploy workflow

With Snakemake and Snakedeploy installed, the workflow can be deployed as follows. First, create an appropriate project working directory on your system and enter it:

mkdir -p path/to/project-workdir
cd path/to/project-workdir

In all following steps, we will assume that you are inside of that directory. Then run

snakedeploy deploy-workflow https://github.com/snakemake-workflows/rna-seq-xengsort . --tag v1.0.0

Snakedeploy will create two folders, workflow and config. The former contains the deployment of the chosen workflow as a Snakemake module, the latter contains configuration files which will be modified in the next step in order to configure the workflow to your needs.

Step 4: Run workflow

The deployment method is controlled using the --software-deployment-method (short --sdm) argument.

To run the workflow using apptainer/singularity, use

snakemake --cores all --sdm apptainer

To run the workflow using a combination of conda and apptainer/singularity for software deployment, use

snakemake --cores all --sdm conda apptainer

To run the workflow with automatic deployment of all required software via conda/mamba, use

snakemake --cores all --sdm conda

Snakemake will automatically detect the main Snakefile in the workflow subfolder and execute the workflow module that has been defined by the deployment in step 2.

For further options such as cluster and cloud execution, see the docs.

Step 5: Generate report

After finalizing your data analysis, you can automatically generate an interactive visual HTML report for inspection of results together with parameters and code inside of the browser using

snakemake --report report.zip

Configuration

The following section is imported from the workflow’s config/README.md.

Workflow overview

This workflow is a best-practice workflow for removing host genome reads from RNAseq data from xenograft samples using xengsort. The workflow is built using snakemake and consists of the following steps:

Adapter trimming with fastp.
Download of the host and graft reference genomes and transcriptomes.
Create a xengsort index hash from the reference.
Use xengsort classify to sort reads into host and graft categories.
Create an updated units.tsv for use in downstream analysis steps.

The workflow is designed, so that its output can easily be used in the rna-seq-kallisto-sleuth workflow. You will most likely want to provide the output that xengsort classify determined as coming from the graft genome as the fq1 and (optionall) fq2 files in that workflow’s units sheet. They will usually be either of the following two options:

For single-end reads: <results>/xengsort_classify/{sample}/{sample}_{unit}.{graft_species}_{graft_build}.{host_species}_{host_build}-graft.fq.gz"
For paired-end reads: <results>/xengsort_classify/{sample}/{sample}_{unit}.{graft_species}_{graft_build}.{host_species}_{host_build}-graft.1.fq.gz" and <results>/xengsort_classify/{sample}/{sample}_{unit}.{graft_species}_{graft_build}.{host_species}_{host_build}-graft.2.fq.gz"

These files relative paths are also written into an updated unit sheet at <results>/units.tsv. To use this in an instance of the rna-seq-kallisto-sleuth workflow, you just have to add the relative to the rna-seq-xengsort workflow instance to the beginning of the fq1 and fq2 paths.

Running the workflow

units sheet

This workflow requires a units sheet similar to the rna-seq-kallisto-sleuth workflow, but with fewer columns. The units sheet has the following layout:

sample	unit	fq1	fq2	fastp_adapters	fastp_extra
sample1	u1	sample1.u1.read1.fastq.gz	sample1.u1.bwa.read2.fastq.gz
sample2	u1	sample2.u1.read1.fastq.gz

The columns sample (sample name), unit (there may be multiple sequenced units per sample), and fq1 are required. fq1 specifies the path to a fastq file for the sample-unit combination. fq2 only specifies a second fastq file for the same sample-unit combination if that sample was sequenced with paired-end reads.

The fastp_adapters and fastp_extra columns should only be used to customize fastp parameters, if the default fastp parameters as described in the rna-seq-kallisto-sleuth workflow do not detect the correct sequencing adapters or if the trimming somehow doesn’t work well. To determine this, check the fastp quality control report as described in the rna-seq-kallisto-sleuth workflow.

config.yaml

This file contains the general workflow configuration. Configurable options should be explained in the comments above the respective entry, so the easiest way to set it up for your workflow is to carefully read through the config/config.yaml file and adjust it to your needs. If something is unclear, don’t hesitate to file an issue in the rna-seq-xengsort GitHub repository.

Workflow parameters

The following table is automatically parsed from the workflow’s config.schema.y(a)ml file.

Parameter	Type	Description	Required	Default
unit_sheet	string	path to sample sheet, mandatory	yes	config/samples.tsv
resources			yes
. ref
. . species	string		yes
. . host_species	string		yes
. . release	string		yes
. . build	string		yes
xengsort			yes
. index			yes
. . nobjects	integer	number of k-mers to store in the hash table	yes
. . kmersize	integer	size of k-mers to store in the hash table	yes
. . bucketsize	integer	number of elements that can be stored in an individual bucket	yes
. . fill	number	desired fill rate of the hash table	yes