Note: if you use
systemPipeR in published research, please cite:
Backman, T.W.H and Girke, T. (2016).
systemPipeR: NGS Workflow and Report Generation Environment. BMC Bioinformatics, 17: 388. 10.1186/s12859-016-1241-0.
systemPipeR provides flexible utilities for building and running automated end-to-end analysis workflows for a wide range of research applications, including next-generation sequencing (NGS) experiments, such as RNA-Seq, ChIP-Seq, VAR-Seq and Ribo-Seq (H Backman and Girke 2016). Important features include a uniform workflow interface across different data analysis applications, automated report generation, and support for running both R and command-line software, such as NGS aligners or peak/variant callers, on local computers or compute clusters (Figure 1). The latter supports interactive job submissions and batch submissions to queuing systems of clusters. For instance,
systemPipeR can be used with most command-line aligners such as
BWA (Li 2013; Li and Durbin 2009),
HISAT2 (Kim, Langmead, and Salzberg 2015),
TopHat2 (Kim et al. 2013) and
Bowtie2 (Langmead and Salzberg 2012), as well as the R-based NGS aligners
Rsubread (Liao, Smyth, and Shi 2013) and
gsnap (gmapR) (Wu and Nacu 2010). Efficient handling of complex sample sets (e.g. FASTQ/BAM files) and experimental designs are facilitated by a well-defined sample annotation infrastructure which improves reproducibility and user-friendliness of many typical analysis workflows in the NGS area (Lawrence et al. 2013).
The main motivation and advantages of using
systemPipeR for complex data analysis tasks are:
Figure 1: Relevant features in
Workflow design concepts are illustrated under (A & B). Examples of
systemPipeR’s visualization functionalities are given under (C).
A central concept for designing workflows within the
is the use of workflow management containers. In previous versions,
used a custom command-line interface called
SYSargs (see Figure 3) and for
this purpose will continue to be supported for some time. With the latest Bioconductor Release 3.9,
we are adopting for this functionality the widely used community standard
Common Workflow Language (CWL) for describing
analysis workflows in a generic and reproducible manner, introducing
workflow control class (see Figure 2). Using this community standard in
has many advantages. For instance, the integration of CWL allows running
workflows from a single specification instance either entirely from within R, from various command-line
wrappers (e.g., cwl-runner) or from other languages (, e.g., Bash or Python).
systemPipeR includes support for both command-line and R/Bioconductor software
as well as resources for containerization, parallel evaluations on computer clusters
along with the automated generation of interactive analysis reports.
An important feature of
systemPipeR's CWL interface is that it provides two
options to run command-line tools and workflows based on CWL. First, one can
run CWL in its native way via an R-based wrapper utility for cwl-runner or
cwl-tools (CWL-based approach). Second, one can run workflows using CWL’s
command-line and workflow instructions from within R (R-based approach). In the
latter case the same CWL workflow definition files (e.g.
are used but rendered and executed entirely with R functions defined by
systemPipeR, and thus use CWL mainly as a command-line and workflow
definition format rather than software to run workflows. In this regard
systemPipeR also provides several convenience functions that are useful for
designing and debugging workflows, such as a command-line rendering function to
retrieve the exact command-line strings for each data set and processing step
prior to running a command-line.
This overview introduces the design of a new CWL S4 class in
as well as the custom command-line interface, combined with the overview of all
the common analysis steps of NGS experiments.
The flexibility of
systemPipeR's new interface workflow control class is the driving factor behind
the use of as many steps necessary for the analysis, as well as the connection
between command-line- or R-based software. The connectivity among all
workflow steps is achieved by the
SYSargs2 workflow control class (see Figure 3).
This S4 class is a list-like container where each instance stores all the
input/output paths and parameter components required for a particular data
SYSargs2 instances are generated by two constructor
functions, loadWorkflow and renderWF,