rnaseq_gene_CSAMA2016.Rmd

---
title: RNA-seq workflow - gene-level exploratory analysis and differential expression
subtitle: CSAMA2016 version
date: July 10, 2016
output: 
  html_document:
    toc: true
bibliography: bibliography.bib
vignette: >
  %\VignetteIndexEntry{RNA-seq workflow at the gene level}
  %\VignetteEngine{knitr::rmarkdown}
---


<!-- to compile this: library("rmarkdown"); render("rnaseq_gene_CSAMA2016.Rmd") -->

<!--
     # a list of all required libraries:
     reqlibs = sub(".*library\\(\"(.*?)\"\\).*","\\1",
       grep("library\\(",readLines("rnaseq_gene_CSAMA2016.Rmd"),value=TRUE))
     find.package(reqlibs)
     cat(paste(reqlibs, collapse="\n"))
-->

<script type="text/javascript"
  src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>


```{r style, echo=FALSE, message=FALSE, warning=FALSE, results="asis"}
library("BiocStyle")
library("knitr")
library("rmarkdown")
options(width=100)
opts_chunk$set(fig.width=5, fig.height=5)
```

# Abstract

Here we walk through an end-to-end gene-level RNA-seq differential
expression workflow using Bioconductor packages.  We will start from
the FASTQ files, show how these were aligned to the reference genome,
and prepare a count matrix which tallies the number of RNA-seq
reads/fragments within each gene for each sample.  We will
perform exploratory data analysis (EDA) for quality assessment and to
explore the relationship between samples, perform differential gene
expression analysis, and visually explore the results.

## Citing scientific research software

If you use the results from an R analysis package in published
research, you can find the proper citation for the software by typing
`citation("pkgName")`, where you would substitute the name of the
package for `pkgName`.  Citing methods papers helps to support and
reward the individuals who put time into open source software for
genomic data analysis.

# Introduction

Bioconductor has many packages which support analysis of
high-throughput sequence 
data, including RNA sequencing (RNA-seq). The packages which we
will use in this workflow include core packages maintained by the
Bioconductor core team for importing and processing raw sequencing
data and loading gene annotations. We will also use
contributed packages for statistical analysis and visualization
of sequencing data. Through scheduled releases every 6 months, the
Bioconductor project ensures that all the packages within a release
will work together in harmony (hence the "conductor" metaphor).
The packages used in this workflow are loaded with the
*library* function and can be installed by following the
[Bioconductor package installation instructions](http://bioconductor.org/install/#install-bioconductor-packages).

A published version of this workflow, including reviewer reports and comments
is available at [F1000Research](http://f1000research.com/articles/4-1070) [@Love2015RNASeq],.

If you have questions about this workflow or any Bioconductor
software, please post these to the
[Bioconductor support site](https://support.bioconductor.org/).
If the questions concern a specific package, you can tag the post with
the name of the package, or for general questions about the workflow,
tag the post with `rnaseqgene`. Note the
[posting guide](http://www.bioconductor.org/help/support/posting-guide/)
for crafting an optimal question for the support site.

## Experimental data

The data used in this workflow is stored in the
`r Biocexptpkg("airway")` package that summarizes an RNA-seq experiment
wherein airway smooth muscle cells were treated with dexamethasone, a
synthetic glucocorticoid steroid with anti-inflammatory effects
[@Himes2014RNASeq].  Glucocorticoids are used, for example, 
by people with asthma to reduce inflammation of the airways. In the experiment,
four human airway smooth muscle cell lines were treated with 1
micromolar dexamethasone for 18 hours. For each of the four cell
lines, we have a treated and an untreated sample. For more description
of the experiment see the article,
[PubMed entry 24926665](http://www.ncbi.nlm.nih.gov/pubmed/24926665),
and for raw data see the
[GEO entry GSE52778](http://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE52778).

## Goal of this workflow

Our goal in this workflow is to bring a summary of the 
RNA-seq experiment into R/Bioconductor for visualization
and statistical testing. We want to visualize the relationships
between the samples (within and across the treatment),
and then we want to perform statistical tests to find which
genes are changing their expression due to treatment.

An overview of the steps we will take (and alternatives) is:

1. Preprocess FASTQ files
    + Align to the genome with STAR or other alignment tools.
    + *or:* Quantify at transcript level using Sailfish, Salmon or kallisto 
      (not covered in this workflow).
2. Summarize into a gene-level count matrix
    + Count number of aligned fragments that can be unambiguously assigned to 
      genes.
    + *or:* Use the `r Biocpkg("tximport")` package to import transcript quantifications
      and summarize to the gene level (not covered in this workflow).
3. Convert the count matrix into a package-specific object, 
   e.g. a *DESeqDataSet* for DESeq2 or a *DGEList* for edgeR.
4. Make exploratory plots, such as PCA plots and sample-sample distance plots.
5. Perform differential expression testing for all genes.
6. Make summary plots of the differential expression results.

# Summarizing an RNA-seq experiment as a count matrix

The count-based statistical methods, such as
`r Biocpkg("DESeq2")` [@Love2014Moderated],
`r Biocpkg("edgeR")` [@Robinson2009EdgeR],
`r Biocpkg("limma")` with the voom method [@Law2014Voom],
`r Biocpkg("DSS")` [@Wu2013New], 
`r Biocpkg("EBSeq")` [@Leng2013EBSeq] and
`r Biocpkg("BaySeq")` [@Hardcastle2010BaySeq],
expect input data as obtained, e.g., from RNA-seq or another high-throughput
sequencing experiment, in the form of a matrix of integer values, or "counts".
The value in the *i*-th row and the *j*-th column of the matrix tells how
many reads (or fragments, for paired-end RNA-seq) have been
unambiguously assigned to gene *i* in sample *j*.  Analogously,
for other types of assays, the rows of the matrix might correspond
e.g., to binding regions (with ChIP-Seq), species of bacteria (with
metagenomic datasets), or peptide sequences (with
quantitative mass spectrometry).

The values in the matrix are counts of sequencing reads (in the case of
single-end sequencing) or fragments (for paired-end sequencing). 
This is important for the count-based statistical models, e.g. *DESeq2* or *edgeR*,
as only the counts allow assessing the measurement precision
correctly. It is important to *never* provide counts that were
normalized for sequencing depth/library size, as the
statistical model is most powerful when applied to counts, and is
designed to account for library size differences internally.

As we will discuss later, an alternative to using raw counts of
reads or fragments aligned to the genome is to use *estimated* counts
from software that use *pseudo-alignment* to the *transcriptome*
[@Soneson2015Differential]. 

## Aligning reads to a reference genome

The computational analysis of an RNA-seq experiment often begins earlier:
we first obtain a set of FASTQ files that
contain the nucleotide sequence of each read and a quality score at
each position. These reads must first be aligned to a reference
genome or transcriptome. It is important to know if the sequencing
experiment was single-end or paired-end, as the alignment software
will require the user to specify both FASTQ files for a paired-end
experiment. The output of this alignment step is commonly stored in a
file format called [SAM/BAM](http://samtools.github.io/hts-specs).

A number of software programs exist to align reads to a reference
genome, and the development is too rapid for this document to provide
an up-to-date list. We recommend consulting benchmarking papers that
discuss the advantages and disadvantages of each software, which
include accuracy, sensitivity in aligning reads over splice junctions, speed,
memory required, usability, and many other features.

The reads for this experiment were aligned to the Ensembl
release 75 [@Flicek2014Ensembl] human reference genome using the
[STAR spliced read aligner](https://code.google.com/p/rna-star/)
[@Dobin2013STAR]. In this example, we have a file in the current
directory called `files` with each line containing an identifier for
each experiment, and we have all the FASTQ files in a subdirectory
`fastq`. If you have downloaded the FASTQ files from the
Sequence Read Archive, the identifiers would be SRA run IDs,
e.g. `SRR1039520`. You should have two files for a paired-end
experiment for each ID, `fastq/SRR1039520_1.fastq1` and
`fastq/SRR1039520_2.fastq`, which give the first and second read for
the paired-end fragments. If you have performed a single-end
experiment, you would only have one file per ID.
We have also created a subdirectory, `aligned`,
where STAR will output its alignment files.

The following chunk of code was run on the command line (outside of R)
to align the paired-end reads to the genome:

```
for f in `cat files`; do STAR --genomeDir ../STAR/ENSEMBL.homo_sapiens.release-75 \
--readFilesIn fastq/$f\_1.fastq fastq/$f\_2.fastq \
--runThreadN 12 --outFileNamePrefix aligned/$f.; done
```

For the latest versions of STAR, the flag `--outSAMtype BAM SortedByCoordinate`
can be added to automatically sort the aligned reads and turn them into 
compressed BAM files.
The BAM files for a number of sequencing runs can then be used to
generate count matrices, as described in the following section.

## Locating BAM files and the sample table

Besides the count matrix that we will use later, the
`r Biocexptpkg("airway")` package also contains eight BAM files 
with a small subset of reads from the experiment --
enough for us to try out counting reads for a small set of genes.

The reads were selected which aligned to a small region of
chromosome 1. We chose a subset of reads because the full alignment files are
large (a few gigabytes each), and because it takes 10-30
minutes to count the full set of fragments for each sample.
We will use these files to demonstrate how a count matrix can be constructed
from BAM files. Afterwards, we will load the full count matrix
corresponding to all samples and all data, which is already provided
in the same package, and will continue the analysis with that full
matrix.

We load the data package with the example data:

```{r message=FALSE}
library("airway")
```

The R function *system.file* can be used to find out where on your
computer the files from a package have been installed. Here we ask for
the full path to the `extdata` directory, where the 
external data that is part of the `r Biocexptpkg("airway")` package 
has been stored.

Note that the use of *system.file* is particular to this workflow,
because we have the data stored in an R package. You would not 
typically use this function for your own pipeline with data
stored in directories on your local machine or cluster.

```{r}
dir <- system.file("extdata", package="airway", mustWork=TRUE)
```

In this directory, we find the eight BAM files (and some other files):

```{r}
list.files(dir)
```

Typically, we have a table with detailed information for each of our
samples that links samples to the associated FASTQ and BAM files.
For your own project, you might create such a comma-separated
value (CSV) file using a text editor or spreadsheet software such as Excel.

We load such a CSV file with *read.csv*:

```{r}
csvfile <- file.path(dir,"sample_table.csv")
sampleTable <- read.csv(csvfile,row.names=1)
sampleTable
```

Once the reads have been aligned, there are a number of tools that
can be used to count the number of reads/fragments that can be
assigned to genomic features for each sample. These often take as
input SAM/BAM alignment files and a file specifying the genomic
features, e.g. a GFF3 or GTF file specifying the gene models.

## *tximport*: transcript abundance summarized to gene-level

An alternative to the alignment-counting workflow is the *tximport* workflow, 
which leverages transcript quantification methods such as 
*Sailfish* [@Patro2014Sailfish],
*Salmon* [@Patro2015Salmon],
*kallisto* [@Bray2015Near],
and *RSEM* [@Li2011RSEM],
to estimate abundances without aligning reads (so skipping
the generation of BAM files). Advantages of using *tximport* to
produce gene-level count matrices and normalizing offsets, are:

1. This approach corrects for potential changes in gene
   length across samples (e.g. from differential isoform usage)
   [@Trapnell2013Differential].
2. Some of these methods are substantially faster and require less memory
    and disk usage compared to alignment-based methods
3.  It is possible to avoid discarding those fragments that
    can align to multiple genes with homologous sequence [@Robert2015Errors].
    Assigning these genes probabilistically and reading in *estimated* counts
    may increase sensitivity.

For more details and example code, 
see the manuscript describing this approach [@Soneson2015Differential]
and the `r Biocpkg("tximport")` package vignette.

## Preparing count matrices from BAM files

The following tools can be used to generate count matrices from
reads aligned to the genome:

* *summarizeOverlaps* from `r Biocpkg("GenomicAlignments")` [@Lawrence2013Software]
* *featureCounts* from `r Biocpkg("Rsubread")` [@Liao2014FeatureCounts]
* *htseq-count* from [HTSeq](http://www-huber.embl.de/users/anders/HTSeq) [@Anders2015HTSeqa]

Each have slightly different output, which can be gathered into a count matrix.
*summarizeOverlaps* produces a *SummarizedExperiment* object, 
which will be discussed below. *featureCounts* produces a count matrix,
and *htseq-count* produces a file for each sample which contains the 
counts per gene.

We will first demonstrate using the *summarizeOverlaps* method of counting.
Using the `Run` column in the sample table, we construct the full
paths to the files we want to perform the counting operation on:

```{r}
filenames <- file.path(dir, paste0(sampleTable$Run, "_subset.bam"))
file.exists(filenames)
```

We indicate in Bioconductor that these files are BAM files using the
*BamFileList* function from the `r Biocpkg("Rsamtools")` package
that provides an R interface to BAM files.
Here we also specify details about how the BAM files should
be treated, e.g., only process 2 million reads at a time. See
`?BamFileList` for more information.

```{r, message=FALSE}
library("Rsamtools")
bamfiles <- BamFileList(filenames, yieldSize=2000000)
```

**Note:** make sure that the chromosome names of the genomic features
in the annotation you use are consistent with the chromosome names of
the reference used for read alignment. Otherwise, the scripts might
fail to count any reads to features due to the mismatching names.
For example, a common mistake is when the alignment files contain
chromosome names in the style of "`1`" and the gene annotation in the
style of "`chr1`", or the other way around. See the *seqlevelsStyle*
function in the `r Biocpkg("GenomeInfoDb")` package for solutions.
We can check the chromosome names (here called "seqnames")
in the alignment files like so:

```{r}
seqinfo(bamfiles[1])
```

## Defining gene models

Next, we need to read in the gene model that will be used for
counting reads/fragments. We will read the gene model from an Ensembl
[GTF file](http://www.ensembl.org/info/website/upload/gff.html) [@Flicek2014Ensembl].
GTF files can be downloaded from
[Ensembl's FTP site](http://www.ensembl.org/info/data/ftp/) or other gene model repositories.

*featureCounts* and *htseq-count* will simply need to know the location
of the GTF file, but for *summarizeOverlaps* we first need to create
an R object that records the location of the exons for each gene. 
We first therefore create a *TxDb* (short for "transcript database"),
using *makeTxDbFromGFF* from the `r Biocpkg("GenomicFeatures")` package.
A *TxDb* object is a database that can be used to
generate a variety of range-based objects, such as exons, transcripts,
and genes. We want to make a list of exons grouped by gene for
counting reads or fragments.

There are other options for constructing a *TxDb*.
For the *known genes* track from the UCSC Genome Browser [@Kent2002Human],
one can use the pre-built Transcript DataBase:
`r Biocannopkg("TxDb.Hsapiens.UCSC.hg19.knownGene")`.
If the annotation file is accessible from
`r Biocpkg("AnnotationHub")` (as is the case for the Ensembl genes),
a pre-scanned GTF file can be imported using *makeTxDbFromGRanges*.
Finally, the *makeTxDbFromBiomart* function can be used to automatically
pull a gene model from Biomart using `r Biocpkg("biomaRt")` [@Durinck2009Mapping].

Here we will demonstrate loading from a GTF file:

```{r, message=FALSE}
library("GenomicFeatures")
gtffile <- file.path(dir,"Homo_sapiens.GRCh37.75_subset.gtf")
txdb <- makeTxDbFromGFF(gtffile, format="gtf")
```

The following line produces a *GRangesList* of all the exons grouped
by gene [@Lawrence2013Software]. Each element of the list is a
*GRanges* object of the exons for a gene.

```{r}
ebg <- exonsBy(txdb, by="gene")
ebg
```

Note that the output here just shows the exons of the first gene. The `ebg`
object contains 19 more genes, ie., for all the 20 genes descibed
in our (very short) example GTF file.

## Counting with summarizeOverlaps

After these preparations, the actual counting is easy. The function
*summarizeOverlaps* from the `r Biocpkg("GenomicAlignments")`
package will do this. This produces a *SummarizedExperiment*
object that contains a variety of information about
the experiment, and will be described in more detail below.

**Note:** If it is desired to perform counting using multiple cores, one can use
the *register* and *MulticoreParam* or *SnowParam* functions from the
`r Biocpkg("BiocParallel")` package before the counting call below.
Expect that the `summarizeOverlaps` call will take at least 30 minutes
per file for a human RNA-seq file with 30 million aligned reads. By sending
the files to separate cores, one can speed up the entire counting process.

```{r}
library("GenomicAlignments")
library("BiocParallel")
```

Most modern laptops have CPUs have with two or four cores, hence we gain a bit of speed
by asking to use two cores. We could have also skipped this line and the counting 
step would run in serial.

```{r}
register(MulticoreParam(2))
```

The following call creates the *SummarizedExperiment* object with counts:

```{r}
se <- summarizeOverlaps(features=ebg, 
                        reads=bamfiles,
                        mode="Union",
                        singleEnd=FALSE,
                        ignore.strand=TRUE,
                        fragments=TRUE )
```

And let's quickly see what we get, before we explain all the arguments:

```{r}
se
```

We specify a number of arguments besides the `features` and the
`reads`. The `mode` argument describes what kind of read overlaps will
be counted. These modes are shown in Figure 1 of the
*Counting reads with summarizeOverlaps* vignette for the
`r Biocpkg("GenomicAlignments")` package.
Note that fragments will be counted only once to each gene, even if
they overlap multiple exons of a gene which may themselves be overlapping.
Setting `singleEnd` to `FALSE`
indicates that the experiment produced paired-end reads, and we want
to count a pair of reads (a fragment) only once toward the count
for a gene. 
The `fragments` argument can be used when `singleEnd=FALSE` to specify if unpaired
reads should be counted (yes if `fragments=TRUE`).

In order to produce correct counts, it is important to know if the
RNA-seq experiment was strand-specific or not. This experiment was not
strand-specific so we set `ignore.strand` to `TRUE`.
However, certain strand-specific protocols could have the reads
align only to the opposite strand of the genes.
The user must check if the experiment was strand-specific and if so,
whether the reads should align to the forward or reverse strand of the genes.
For various counting/quantifying tools, one specifies counting on the
forward or reverse strand in different ways, although this task 
is currently easiest with *htseq-count*, *featureCounts*, or the
transcript abundance quantifiers mentioned previously.
It is always a good idea to check the column sums of the count matrix
(see below) to make sure these totals match the expected of the number
of reads or fragments aligning to genes.  Additionally, one can
visually check the read alignments using a genome visualization tool.

## SummarizedExperiment

We will now explain all the parts of the object we obtained 
from *summarizeOverlaps*.
The following figure illustrates the structure of 
a *SummarizedExperiment* object.

```{r sumexp, echo = FALSE}
par(mar=c(0,0,0,0))
plot(1,1,xlim=c(0,100),ylim=c(0,100),bty="n",
   type="n",xlab="",ylab="",xaxt="n",yaxt="n")
polygon(c(45,90,90,45),c(5,5,70,70),col="pink",border=NA)
polygon(c(45,90,90,45),c(68,68,70,70),col="pink3",border=NA)
text(67.5,40,"assay")
text(67.5,35,'e.g. "counts"')
polygon(c(10,40,40,10),c(5,5,70,70),col="skyblue",border=NA)
polygon(c(10,40,40,10),c(68,68,70,70),col="skyblue3",border=NA)
text(25,40,"rowRanges")
text(25,35,'(with "mcols")')
polygon(c(45,90,90,45),c(75,75,95,95),col="palegreen",border=NA)
polygon(c(45,47,47,45),c(75,75,95,95),col="palegreen3",border=NA)
text(67.5,85,"colData",srt=90)
```

The `assay` (pink block) contains the matrix of counts, 
the `rowRanges` (blue block) contains information about 
the genomic ranges, and 
the `colData` (green block) contains information about 
the samples. 
The highlighted line in each block represents the first row 
(note that the first row of `colData` lines up with the 
first column of the `assay`). 

The *SummarizedExperiment* container is diagrammed in the Figure above
and discussed in the latest Bioconductor paper [@Huber2015Orchestrating].
In our case we have created a single matrix named "counts" that contains the fragment
counts for each gene and sample.
The component parts of the *SummarizedExperiment* are accessed with an
R function of the same name: `assay` (or `assays`), `rowRanges` and `colData`.

The counts are accessed using `assay`: 

```{r}
head( assay(se) )
```

We can ask the dimension of the *SummarizedExperiment* (the dimension of the
assay matrix), simply with `dim`:

```{r}
dim(se)
nrow(se)
ncol(se)
```

As we see, in this experiment there are 20 genes and 8 samples. 
It is also possible to store multiple matrices in a *SummarizedExperiment* 
object, and to access them with `assays`.

The `rowRanges` for our object is the *GRangesList* we used for
counting (one *GRanges* of exons for each row of the count matrix).

```{r}
rowRanges(se)
length(rowRanges(se))
rowRanges(se)[[1]]
```

The `rowRanges` also contains metadata about the construction
of the gene model in the `metadata` slot. Here we use a helpful R
function, `str`, to display the metadata compactly:

```{r}
str(metadata(rowRanges(se)))
```

The `colData` stores the metadata about the samples:

```{r}
colData(se)
```

The `colData` slot is so far empty! 

Because we used a column of `sampleTable` to produce the `bamfiles`
vector, we know the columns of `se` are in the same order as the
rows of `sampleTable`. Take a moment to convince yourself this is true:

```{r}
colnames(se)
bamfiles
sampleTable$Run
```

We can assign the `sampleTable` as the
`colData` of the summarized experiment, by converting
it into a *DataFrame* and using the assignment function:

```{r}
colData(se) <- DataFrame(sampleTable)
colData(se)
```

We are now finished exploring the parts of the *SummarizedExperiment*.

## Alternative - Counting with featureCounts in Rsubread

Another option for counting reads or fragments within R/Bioconductor
is the `r Biocpkg("Rsubread")` package which contains the *featureCounts*
function [@Liao2014FeatureCounts]. 
This is very simple to use and very fast, and returns the count
matrix as part of the result. See `?featureCounts` for more information on 
its usage, including how to sort the BAM files for fastest counting.

When you run *featureCounts* you will see a large logo
printed to your screen as well as other information
displayed live as the software is counting. 

```{r}
library("Rsubread")
fc <- featureCounts(files=filenames, 
                    annot.ext=gtffile, 
                    isGTFAnnotationFile=TRUE,
                    isPairedEnd=TRUE)
colnames(fc$counts) <- sampleTable$Run
head(fc$counts)
```

## Branching point

At this point, we have counted the fragments which overlap the genes
in the gene model we specified. This is a branching point where we
could use a variety of Bioconductor packages for exploration and
differential expression of the count matrix, including
`r Biocpkg("edgeR")` [@Robinson2009EdgeR],
`r Biocpkg("limma")` with the voom method [@Law2014Voom],
`r Biocpkg("DSS")` [@Wu2013New],
`r Biocpkg("EBSeq")` [@Leng2013EBSeq] and
`r Biocpkg("BaySeq")` [@Hardcastle2010BaySeq].

We will continue, using `r Biocpkg("DESeq2")` [@Love2014Moderated]
and `r Biocpkg("edgeR")` [@Robinson2009EdgeR].
Each of these packages has a specific class of object used
to store the summarization of the RNA-seq experiment, 
and the intermediate quantities that are calculated during
the statistical analysis of the data.
*DESeq2* uses a *DESeqDataSet* and *edgeR* uses a *DGEList*.

# The *DESeqDataSet*, sample information, and the design formula

Bioconductor software packages often define and use a custom class for
storing data that makes sure that all the needed data slots are
consistently provided and fulfill the requirements.  In addition,
Bioconductor has general data classes (such as the
*SummarizedExperiment*) that can be used to move data between
packages. Additionally, the core Bioconductor classes provide useful
functionality: for example, subsetting or reordering the rows or
columns of a *SummarizedExperiment* automatically subsets or reorders
the associated *rowRanges* and *colData*, which can help to prevent
accidental sample swaps that would otherwise lead to spurious
results. With *SummarizedExperiment* this is all taken care of behind
the scenes.

In *DESeq2*, the custom class is called *DESeqDataSet*. It is built on
top of the *SummarizedExperiment* class, and it is easy to convert
*SummarizedExperiment* objects into *DESeqDataSet* objects, which we
show below.  One of the two main differences is that the `assay` slot is
instead accessed using the *counts* accessor function, and the
*DESeqDataSet* class enforces that the values in this matrix are
non-negative integers.

A second difference is that the *DESeqDataSet* has an associated
*design formula*. The experimental design is specified at the
beginning of the analysis, as it will inform many of the *DESeq2*
functions how to treat the samples in the analysis (one exception is
the size factor estimation, i.e., the adjustment for differing library
sizes, which does not depend on the design formula).  The design
formula tells which columns in the sample information table (`colData`)
specify the experimental design and how these factors should be used
in the analysis.

The simplest design formula for differential expression would be
`~ condition`, where `condition` is a column in `colData(dds)` that
specifies which of two (or more groups) the samples belong to.  

However, let's remind ourselves of the experimental design of the experiment:

```{r}
colData(se)
```

We have treated and untreated samples (as indicated by `dex`):

```{r}
se$dex
```

We also have four different cell lines:

```{r}
se$cell 
```

We want to compare the differences in gene expression that can 
be associated with dexamethasone treatment, but we also want
to control for differences across the four cell lines.
The design which accomplishes this is to write `~ cell + dex`.
By including `cell`, terms will be added to the model
which account for differences across cell, and by adding `dex`
we get a single term which explains the differences across
treated and untreated samples.

**Note:** it will be helpful for us if the first level of a factor be the
reference level (e.g. control, or untreated samples).
The reason is that, by specifying this, functions further
in the pipeline can be used and will give comparisons such as,
treatment vs control, without needing to specify additional arguments.

We can *relevel* the `dex` factor like so: 

```{r}
se$dex <- relevel(se$dex, "untrt")
se$dex
```

It is not important for us to *relevel* the `cell` variable,
nor is there a clear reference level for cell line.

For running *DESeq2* or *edgeR* models, you can use R's formula notation to
express any fixed-effects experimental design.
Note that these packages use the same formula notation as, for instance, the *lm*
function of base R. If the research aim is to determine for which
genes the effect of treatment is different across groups, then
interaction terms can be included and tested using a design such as
`~ group + treatment + group:treatment`. See the vignettes of *DESeq2* and
*edgeR* for more examples.

In the following sections, we will demonstrate the construction of the
*DESeqDataSet* from two starting points:

* from a *SummarizedExperiment* object 
* from a count matrix and a sample information table

## Starting from *SummarizedExperiment*

We now use R's *data* command to load a prepared
*SummarizedExperiment* that was generated from the publicly available
sequencing data files associated with @Himes2014RNASeq,
described above.  The steps we used to produce this object were
equivalent to those you worked through in the previous sections,
except that we used all the reads and all the genes. For more details
on the exact steps used to create this object, type
`vignette("airway")` into your R session. 

```{r}
data("airway")
se <- airway
```

## Pre-filtering rows with very small counts

This *SummarizedExperiment* contains many rows (genes)
with zero or very small counts. In order to streamline the
workflow, which uses multiple packages, we will remove 
those genes which have a total count of less than 5:

```{r}
se <- se[ rowSums(assay(se)) >= 5, ]
```

Again, we want to specify that `untrt` is the reference level for the
dex variable:

```{r}
se$dex <- relevel(se$dex, "untrt")
se$dex
```

Supposing we have constructed a *SummarizedExperiment* using
one of the methods described in the previous section, we now need to
make sure that the object contains all the necessary information about
the samples, i.e., a table with metadata on the count matrix's columns
stored in the `colData` slot:

```{r}
colData(se)
```

Here we see that this object already contains an informative
`colData` slot -- because we have already prepared it for you, as
described in the `r Biocexptpkg("airway")` vignette.
However, when you work with your own data, you will have to add the
pertinent sample / phenotypic information for the experiment at this stage.
We highly recommend keeping this information in a comma-separated
value (CSV) or tab-separated value (TSV) file, which can be exported
from an Excel spreadsheet, and the assign this to the `colData` slot,
making sure that the rows correspond to the columns of the
*SummarizedExperiment*. We made sure of this correspondence earlier by
specifying the BAM files using a column of the sample table.

Once we have our fully annotated *SummarizedExperiment* object,
we can construct a *DESeqDataSet* object from it that will then form
the starting point of the analysis.
We add an appropriate design for the analysis:

```{r message=FALSE}
library("DESeq2")
dds <- DESeqDataSet(se, design = ~ cell + dex)
```

## Starting from count matrices

In this section, we will show how to build an *DESeqDataSet* supposing
we only have a count matrix and a table of sample information.

**Note:** if you have prepared a *SummarizedExperiment* you should skip this
section. While the previous section would be used to construct a
*DESeqDataSet* from a *SummarizedExperiment*, here we first extract
the individual object (count matrix and sample info) from the
*SummarizedExperiment* in order to build it back up into a new object
-- only for demonstration purposes.
In practice, the count matrix would either be read in from a file or
perhaps generated by an R function like *featureCounts* from the
`r Biocpkg("Rsubread")` package [@Liao2014FeatureCounts].

The information in a *SummarizedExperiment* object can be
accessed with accessor functions. For example, to see the actual data,
i.e., here, the fragment counts, we use the *assay* function. (The *head*
function restricts the output to the first few lines.)

```{r}
countdata <- assay(se)
head(countdata, 3)
```

In this count matrix, each row represents an Ensembl gene, each column
a sequenced RNA library, and the values give the raw numbers of
fragments that were uniquely assigned to the respective gene in each
library. We also have information on each of the samples (the columns of the
count matrix). If you've counted reads with some other software, it is
very important to check that the columns of the count matrix correspond to the rows
of the sample information table. 

```{r}
coldata <- colData(se)
```

We now have all the ingredients to prepare our data object in a form
that is suitable for analysis, namely:

* `countdata`: a table with the fragment counts
* `coldata`: a table with information about the samples

To now construct the *DESeqDataSet* object from the matrix of counts and the
sample information table, we use:

```{r}
ddsMat <- DESeqDataSetFromMatrix(countData = countdata,
                                  colData = coldata,
                                  design = ~ cell + dex)
```

## Creating a DGEList for use with edgeR

As mentioned above, the edgeR package uses another type of data container,
namely a DGEList object. It is just as easy to create a *DGEList* object using
the count matrix and information about samples. We can additionally add
information about the genes:

```{r message=FALSE}
library("edgeR")
genetable <- data.frame(gene.id=rownames(se))
y <- DGEList(counts=countdata, 
             samples=coldata, 
             genes=genetable)
names(y)
```

Just like the *SummarizedExperiment* and the *DESeqDataSet*
the *DGEList* contains all the information we need to know:
the count matrix, information about the samples (columns 
of the count matrix), and information about the genes 
(rows of the count matrix).

# Exploratory analysis and visualization

There are two separate paths in this workflow:

1. *visually exploring* sample relationships, in which
   we will discuss transformation of the counts for 
   computing distances or making plots
2. *statistical testing* for differences attributable to 
   treatment, controlling for cell line effects

Importantly, the statistical testing methods rely on original count data (not
scaled or transformed) for calculating the precision of measurements. However,
for visualization and exploratory analysis, transformed counts are typically
more suitable. Thus, it is critical to separate the two workflows and use the 
appropriate input data for each of them.

## Transformations

Many common statistical methods for exploratory analysis of
multidimensional data, for example clustering and *principal
components analysis* (PCA), work best for data that generally has the
same range of variance at different ranges of the mean values. When
the expected amount of variance is approximately the same across
different mean values, the data is said to be *homoskedastic*.  For
RNA-seq raw counts, however, the variance grows with the mean.  For
example, if one performs PCA directly on a matrix of
size-factor-normalized read counts, the result typically depends only
on the few most strongly expressed genes because they show the largest
absolute differences between samples.  A simple and often used
strategy to avoid this is to take the logarithm of the normalized
count values plus a small pseudocount; however, now the genes with the
very lowest counts will tend to dominate the results because, due to
the strong Poisson noise inherent to small count values, and the fact
that the logarithm amplifies differences for the smallest values,
these low count genes will show the strongest relative differences
between samples.

As a solution, *DESeq2* offers transformations for count data that
stabilize the variance across the mean: the *regularize logarithm* (rlog) and the 
*variance stabilizing transformation* (VST).
These have slightly different implementations, discussed a bit
in the *DESeq2* paper and in the vignette, but a similar goal of stablizing
the variance across the range of values. Both produce log2-like values
for high counts. Here we will use the variance stabilizing transformation implemented with the `vst` function:

```{r}
vsd <- vst(dds)
```

This returns a *DESeqTransform* object

```{r}
class(vsd)
```

...which contains all the 
column metadata that was attached to the *DESeqDataSet*:

```{r}
head(colData(vsd),3)
```


## PCA plot

Another way to visualize sample-to-sample distances is a
principal components analysis (PCA). In this ordination method, the
data points (here, the samples) are projected onto the 2D plane
such that they spread out in the two directions that explain most of
the differences (Figure below). The x-axis is the direction that separates the data
points the most. The values of the samples in this direction are
written *PC1*. The y-axis is a direction (it must be *orthogonal* to
the first direction) that separates the data the second most. The
values of the samples in this direction are written *PC2*.
The percent of the total variance that is contained in the direction
is printed in the axis label. Note that these percentages do not add to
100%, because there are more dimensions that contain the remaining
variance (although each of these remaining dimensions will explain
less than the two that we see). 

```{r plotpca, fig.width=6, fig.height=4.5}
plotPCA(vsd, "dex")
```

We can also build the PCA plot from scratch using the
`r CRANpkg("ggplot2")` package [@Wickham2009Ggplot2].
This is done by asking the *plotPCA* function
to return the data used for plotting rather than building the plot.
See the *ggplot2* [documentation](http://docs.ggplot2.org/current/)
for more details on using *ggplot*.

```{r}
data <- plotPCA(vsd, intgroup = c( "dex", "cell"), returnData=TRUE)
percentVar <- round(100 * attr(data, "percentVar"))
```

We can then use this data to build up a second plot in a Figure below, specifying that the
color of the points should reflect dexamethasone treatment and the
shape should reflect the cell line.

```{r ggplotpca, message=FALSE, fig.width=6, fig.height=4.5}
library("ggplot2")
ggplot(data, aes(PC1, PC2, color=dex, shape=cell)) + geom_point(size=3) +
  xlab(paste0("PC1: ",percentVar[1],"% variance")) +
  ylab(paste0("PC2: ",percentVar[2],"% variance"))
```

Here we specify cell line (plotting symbol) and dexamethasone treatment (color).

From the PCA plot, we see that the differences between cells (the
different plotting shapes) are considerable, though not stronger than the differences due to
treatment with dexamethasone (red vs blue color). This shows why it will be important to
account for the cell line effect in differential testing by using a paired design
("paired", because each dex treated sample is paired with one
untreated sample from the *same* cell line). We are already set up for
this design by assigning the formula `~ cell + dex` earlier.

## MDS plot

Another way to reduce dimensionality, which is in many ways similar to PCA, is 
*multidimensional scaling* (MDS). For MDS, we first have to calculate all
pairwise distances between our objects (samples in this case), and then create a
(typically) two-dimensional representation where these pre-calculated distances
are represented as accurately as possible. This means that depending on how the
pairwise sample distances are defined, the two-dimensional plot can be very
different, and it is important to choose a distance that is suitable for the
type of data at hand.

edgeR contains a function `plotMDS`, which operates on a `DGEList` object and
generates a two-dimensional MDS representation of the samples. The default 
distance between two samples can be interpreted as the "typical" log fold change
between the two samples, for the genes that are most different between them (by 
default, the top 500 genes, but this can be modified as shown below). We
generate an MDS plot from the `DGEList` object `y`, coloring by the treatment
and using different plot symbols for different cell lines.

```{r}
y <- calcNormFactors(y)
plotMDS(y, top = 1000, labels = NULL, col = as.numeric(y$samples$dex), 
        pch = as.numeric(y$samples$cell), cex = 2)
```

We can also perform MDS on manually calculated distances, using the R function
`cmdscale`. Below we show how to do this starting from the VST counts, using
Euclidean distance.

```{r mdsrlog, fig.width=6, fig.height=4.5}
sampleDists <- dist(t(assay(vsd)))
sampleDistMatrix <- as.matrix( sampleDists )
mdsData <- data.frame(cmdscale(sampleDistMatrix))
mds <- cbind(mdsData, as.data.frame(colData(vsd)))
ggplot(mds, aes(X1,X2,color=dex,shape=cell)) + geom_point(size=3)
```

In a Figure below we show the same plot for the *PoissonDistance*:

```{r mdspois, fig.width=6, fig.height=4.5}
library("PoiClaClu")
poisd <- PoissonDistance(t(counts(dds)))
samplePoisDistMatrix <- as.matrix( poisd$dd )
mdsPoisData <- data.frame(cmdscale(samplePoisDistMatrix))
mdsPois <- cbind(mdsPoisData, as.data.frame(colData(dds)))
ggplot(mdsPois, aes(X1,X2,color=dex,shape=cell)) + geom_point(size=3)
```

# Differential expression analysis

## Performing differential expression testing with DESeq2

As we have already specified an experimental design when we created
the *DESeqDataSet*, we can run the differential expression pipeline on
the raw counts with a single call to the function *DESeq*:

```{r DESeq2call}
dds <- DESeq(dds)
```

This function will print out a message for the various steps it
performs. These are described in more detail in the manual page for
*DESeq*, which can be accessed by typing `?DESeq`. Briefly these are:
the estimation of size factors (controlling for differences in the
sequencing depth of the samples), the estimation of
dispersion values for each gene, and fitting a generalized linear model.

A *DESeqDataSet* is returned that contains all the fitted
parameters within it, and the following section describes how to
extract out results tables of interest from this object.

We will show in a following section how to perform
differential testing using edgeR.

## Building the results table

Calling *results* without any arguments will extract the estimated
log2 fold changes and *p* values for the last variable in the design
formula. If there are more than 2 levels for this variable, *results*
will extract the results table for a comparison of the last level over
the first level. This comparison is printed at the top of the output:
`dex trt vs untrt`.

```{r}
res <- results(dds)
```

As `res` is a *DataFrame* object, it carries metadata
with information on the meaning of the columns:

```{r}
mcols(res, use.names=TRUE)
```

The first column, `baseMean`, is a just the average of the normalized
count values, dividing by size factors, taken over all samples in the
*DESeqDataSet*.
The remaining four columns refer to a specific contrast, namely the
comparison of the `trt` level over the `untrt` level for the factor
variable `dex`. We will find out below how to obtain other contrasts.

The column `log2FoldChange` is the effect size estimate. It tells us
how much the gene's expression seems to have changed due to treatment
with dexamethasone in comparison to untreated samples.  This value is
reported on a logarithmic scale to base 2: for example, a log2 fold
change of 1.5 means that the gene's expression is increased by a
multiplicative factor of \(2^{1.5} \approx 2.82\).

Of course, this estimate has an uncertainty associated with it, which
is available in the column `lfcSE`, the standard error estimate for
the log2 fold change estimate.  We can also express the uncertainty of
a particular effect size estimate as the result of a statistical
test. The purpose of a test for differential expression is to test
whether the data provides sufficient evidence to conclude that this
value is really different from zero. *DESeq2* performs for each gene a
*hypothesis test* to see whether evidence is sufficient to decide
against the *null hypothesis* that there is zero effect of the treatment
on the gene and that the observed difference between treatment and
control was merely caused by experimental variability (i.e., the type
of variability that you can expect between different
samples in the same treatment group). As usual in statistics, the
result of this test is reported as a *p* value, and it is found in the
column `pvalue`. Remember that a *p* value indicates the probability
that a fold change as strong as the observed one, or even stronger,
would be seen under the situation described by the null hypothesis.

We can also summarize the results with the following line of code,
which reports some additional information, that will be covered in
later sections.

```{r}
summary(res)
```

Note that there are many genes with differential expression due to
dexamethasone treatment at the FDR level of 10%. This makes sense, as
the smooth muscle cells of the airway are known to react to
glucocorticoid steroids. However, there are two ways to be more strict
about which set of genes are considered significant:

* lower the false discovery rate threshold (the threshold on `padj` in
  the results table)
* raise the log2 fold change threshold from 0 using the `lfcThreshold`
  argument of *results*

If we lower the false discovery rate threshold, we should also
tell this value to `results()`, so that the function will use an
alternative threshold for the optimal independent filtering step:

```{r}
res.05 <- results(dds, alpha=.05)
table(res.05$padj < .05)
```

If we want to raise the log2 fold change threshold, so that we test
for genes that show more substantial changes due to treatment, we
simply supply a value on the log2 scale. For example, by specifying
`lfcThreshold=1`, we test for genes that show significant effects of
treatment on gene counts more than doubling or less than halving,
because \(2^1 = 2\).

```{r}
resLFC1 <- results(dds, lfcThreshold=1)
table(resLFC1$padj < 0.1)
```

Sometimes a subset of the *p* values in `res` will be `NA` ("not
available"). This is *DESeq*'s way of reporting that all counts for
this gene were zero, and hence no test was applied. In addition, *p*
values can be assigned `NA` if the gene was excluded from analysis
because it contained an extreme count outlier. For more information,
see the outlier detection section of the *DESeq2* vignette.

## Performing differential expression testing with edgeR

Next we will show how to perform differential expression analysis with *edgeR*.
Recall that we have a `DGEList` `y`, containing three objects:

```{r}
names(y)
```

We first define a design matrix, using the same formula syntax as for *DESeq2*
above.

```{r}
design <- model.matrix(~ cell + dex, y$samples)
```

Then, we calculate normalization factors and estimate the dispersion for each
gene. Note that we need to specify the design in the dispersion calculation.

```{r}
y <- calcNormFactors(y)
y <- estimateDisp(y, design)
```

Finally, we fit the generalized linear model and perform the test. In the
`glmLRT` function, we indicate which coefficient (which column in the design
matrix) that we would like to test for. It is possible to test more general 
contrasts as well, and the user guide contains many examples on how to do this.
The `topTags` function extracts the top-ranked genes. You can indicate the
adjusted p-value cutoff, and/or the number of genes to keep.

```{r edgeRcall}
fit <- glmFit(y, design)
lrt <- glmLRT(fit, coef=ncol(design))
tt <- topTags(lrt, n=nrow(y), p.value=0.1)
tt10 <- topTags(lrt) # just the top 10 by default
tt10
```

We can compare to see how the results from the two software
overlap:

```{r}
tt.all <- topTags(lrt, n=nrow(y), sort.by="none")
table(DESeq2=res$padj < 0.1, edgeR=tt.all$table$FDR < 0.1)
```

Also with edgeR we can test for significance relative to a fold-change 
threshold, using the function `glmTreat` instead of `glmLRT`. Below we set the
log fold-change threshold to 1 (i.e., fold change threshold equal to 2), as for
DESeq2 above. We also compare the results to those obtained with DESeq2.

```{r}
treatres <- glmTreat(fit, coef = ncol(design), lfc = 1)
tt.treat <- topTags(treatres, n = nrow(y), sort.by = "none")
table(DESeq2 = resLFC1$padj < 0.1, edgeR = tt.treat$table$FDR < 0.1)
```

We can compare the two lists by the ranks:

```{r}
common <- !is.na(res$padj)
plot(rank(res$padj[common]), 
     rank(tt.all$table$FDR[common]), cex=.1,
     xlab="DESeq2", ylab="edgeR")
```


## Multiple testing

In high-throughput biology, we are careful to not use the *p* values
directly as evidence against the null, but to correct for
*multiple testing*. What would happen if we were to simply threshold
the *p* values at a low value, say 0.05? There are
`r sum(res$pvalue < .05, na.rm=TRUE)` genes with a *p* value
below 0.05 among the `r sum(!is.na(res$pvalue))` genes, for which the
test succeeded in reporting a *p* value:

```{r}
sum(res$pvalue < 0.05, na.rm=TRUE)
sum(!is.na(res$pvalue))
```

Now, assume for a moment that the null hypothesis is true for all
genes, i.e., no gene is affected by the treatment with
dexamethasone. Suppose we are interesting in a significance level of 0.05.
Then, by the definition of the *p* value, we expect up to
5% of the genes to have a *p* value below 0.05. This amounts to

```{r}
round(sum(!is.na(res$pvalue)) * .05)
```

If we just considered the list of genes with a *p* value below 0.05 as
differentially expressed, this list should therefore be expected to
contain many false positives:

```{r}
round(sum(!is.na(res$pvalue)) * .05) # expected 'null' less than 0.05
sum(res$pvalue < .05, na.rm=TRUE) # observed p < .05
# expected ratio of false positives in the set with p < .05
round(sum(!is.na(res$pvalue))*.05 / sum(res$pvalue < .05, na.rm=TRUE), 2)
```

*DESeq2* and *edgeR* use the Benjamini-Hochberg (BH) 
adjustment [@Benjamini1995Controlling] as implemented in
the base R *p.adjust* function; in brief, this method calculates for
each gene an adjusted *p* value that answers the following question:
if one called significant all genes with an adjusted *p* value less than or
equal to this gene's adjusted *p* value threshold, what would be the fraction
of false positives (the *false discovery rate*, FDR) among them, in
the sense of the calculation outlined above? These values, called the
BH-adjusted *p* values, are given in the column `padj` of the `res`
object.

The FDR is a useful statistic for many high-throughput
experiments, as we are often interested in reporting or focusing on a
set of interesting genes, and we would like to put an upper bound on the
percent of false positives in this set. 

Hence, if we consider a fraction of 10% false positives acceptable,
we can consider all genes with an adjusted *p* value below 10% = 0.1
as significant. How many such genes are there?

```{r}
sum(res$padj < 0.1, na.rm=TRUE)
```

# Plotting results

A quick way to visualize the counts for a particular gene is to use
the *plotCounts* function that takes as arguments the
*DESeqDataSet*, a gene name, and the group over which to plot the
counts (Figure below).

```{r plotcounts}
topGene <- rownames(res)[which.min(res$padj)]
plotCounts(dds, topGene, "dex")
```

## MA plot with DESeq2

An *MA-plot* [@Dudoit2002Statistical] provides a useful overview for an experiment with a
two-group comparison (Figure below).

```{r plotma}
DESeq2::plotMA(res, ylim=c(-5,5))
```

The log2 fold change for a particular
comparison is plotted on the y-axis and the average of the counts
normalized by size factor is shown on the x-axis ("M" for minus,
because a log ratio is equal to log minus log, and "A" for average).
Each gene is represented with a dot. Genes with an adjusted *p* value
below a threshold (here 0.1, the default) are shown in red.

The *DESeq2* package uses statistical techniques to moderate log2 fold
changes from genes with very low counts and highly variable counts, as
can be seen by the narrowing of the vertical spread of points on the
left side of the MA-plot. For a detailed explanation of the rationale
of moderated fold changes, please see the *DESeq2* paper
[@Love2014Moderated].  This plot demonstrates that only genes with a
large average normalized count contain sufficient information to yield
a significant call.

## MA / Smear plot with edgeR

In *edgeR*, the MA plot is obtained via the `plotSmear` function. 

```{r}
plotSmear(lrt, de.tags=tt$table$gene.id)
```

## Heatmap of the most significant genes

```{r}
library("pheatmap")
mat <- assay(vsd)[ head(order(res$padj),30), ]
mat <- mat - rowMeans(mat)
df <- as.data.frame(colData(vsd)[,c("cell","dex")])
pheatmap(mat, annotation_col=df)
```


# Annotating and exporting results

Our result table so far only contains Ensembl gene
IDs, but actual gene names may be more informative for
interpretation.  Bioconductor's annotation packages help with mapping
various ID schemes to each other.
We load the `r Biocpkg("AnnotationDbi")` package and the annotation package
`r Biocannopkg("Homo.sapiens")`:

```{r}
library("AnnotationDbi")
library("Homo.sapiens")
```

To get a list of all available key types, use:

```{r}
columns(Homo.sapiens)
```

We can use the *mapIds* function to add individual columns to our results
table. We provide the row names of our results table as a key, and
specify that `keytype=ENSEMBL`. The `column` argument tells the
*mapIds* function which information we want, and the `multiVals`
argument tells the function what to do if there are multiple possible
values for a single input value. Here we ask to just give us back the
first one that occurs in the database.
To add the gene symbol and Entrez ID, we call *mapIds* twice.

```{r}
res$symbol <- mapIds(Homo.sapiens,
                     keys=row.names(res),
                     column="SYMBOL",
                     keytype="ENSEMBL",
                     multiVals="first")
y$genes$symbol <- res$symbol

res$entrez <- mapIds(Homo.sapiens,
                     keys=row.names(res),
                     column="ENTREZID",
                     keytype="ENSEMBL",
                     multiVals="first")
y$genes$entrez <- res$entrez

res$symbol <- mapIds(Homo.sapiens,
                     keys=row.names(res),
                     column="GENENAME",
                     keytype="ENSEMBL",
                     multiVals="first")
y$genes$symbol <- res$symbol
```

Now the results have the desired external gene IDs:

```{r}
resOrdered <- res[order(res$padj),]
head(resOrdered)
```

## Exporting results to CSV file

You can easily save the results table in a CSV file, that you can
then share or load with a spreadsheet program such as Excel. The call to
*as.data.frame* is necessary to convert the *DataFrame* object
(`r Biocpkg("IRanges")` package) to a *data.frame* object that can be
processed by *write.csv*. Here, we take just the top 100 genes for
demonstration.

```{r eval=FALSE}
resOrderedDF <- as.data.frame(resOrdered)[seq_len(100),]
write.csv(resOrderedDF, file="results.csv")
```

## Exporting results to Glimma

`r Biocpkg("Glimma")` is a new package in Bioconductor which allows one to 
build interactive HTML pages that summarize the results of an
edgeR, limma or DESeq2 analysis. See the *Glimma* vignette
for more details on how to customize this HTML page and what
other plots are available.

Note that the Glimma functions take a minute to build.

edgeR results:

```{r eval=FALSE}
library("Glimma")
glMDPlot(lrt, 
         counts=y$counts, 
         anno=y$genes, 
         groups=y$samples$dex, 
         samples=colnames(y),
         status=tt.all$table$FDR < 0.1,
         id.column="gene.id")
```

DESeq2 results:

```{r eval=FALSE}
res.df <- as.data.frame(res)
res.df$log10MeanNormCount <- log10(res.df$baseMean)
idx <- rowSums(counts(dds)) > 0
res.df <- res.df[idx,]
res.df$padj[is.na(res.df$padj)] <- 1
glMDPlot(res.df,
         xval="log10MeanNormCount",
         yval="log2FoldChange",
         counts=counts(dds)[idx,],
         anno=data.frame(GeneID=rownames(dds)[idx]),
         groups=dds$dex,
         samples=colnames(dds),
         status=res.df$padj < 0.1,
         display.columns=c("symbol", "entrez"))
```

# Gene set overlap analysis

Now that we have obtained a list of genes that are significantly up- 
or down-regulated in response to treatment, a natural question is:
What do these genes have in common? A simple way to answer this is
to compare with a gene set collection, i.e., a collection of sets 
of genes, which have something specific in common. For each such set,
we ask? Are the genes in this set significantly enriched in our list
of down-regulated genes, i.e., do they appear more often in this list 
as one would expect by chance? As explained in the lecture, the 
hypergeometric test (also called Fisher's test) is often used for this 
purpose. 

The Gene Ontology (GO) is a controlled vocabular of terms used to describe what it 
known about genes' function with respect to three aspects, namely
their molecular function (MF), the biological process (BP) they play a role
in, and the cellular component (CC) the gene's product is part of. The
annotation package `r Biocannopkg("org.Hs.eg.db")` (part of the package
`r Biocannopkg("Homo.sapiens")`, which we have already 
used above), contains mappings of human genes to GO terms. The 
`r Biocpkg("topGO")` package [@Alexa2006Improved] offers a simple way to perform 
enrichment tests for all the GO terms, which we demonstrate now.

First, we should subset our result table to only those genes that had suffient read
coverage that we could actually test for differential expression. In DESeq2, we
can simply take the genes that survived independent filtering (see above) and hence
got assigned an adjusted p value.

We will use the set of genes that had evidence of a fold change greater than 2 
(log2 fold change greater than 1):

```{r}
resTested <- resLFC1[ !is.na(resLFC1$padj), ]
```

Then, we construct a factor containing ones and zeroes to indicate which of these genes
were significantly up-regulated and which not. We name the vector elements with
the Ensembl gene IDs.

```{r}
genelistUp <- factor( as.integer( resTested$padj < .1 & resTested$log2FoldChange > 0 ) )
names(genelistUp) <- rownames(resTested)
```

Now, we load the topGO package and prepare a data structure for testing. 

```{r message=FALSE}
library("topGO")

myGOdata <- new( "topGOdata",
   ontology = "BP",
   allGenes = genelistUp,
   nodeSize = 10,
   annot = annFUN.org, mapping = "org.Hs.eg.db", ID="ensembl" )
```

Here, we have indicated that we want to work within the Biological Processes (BP) 
sub-ontology, use only sets with at least 10 genes, and that the names of our
gene list are Ensembl IDs, which are mapped to GO terms in the `org.Hs.eg.db`
annotation database object.

We run Fisher tests and choose topGO's "elim" algorithm, which eliminates broader terms
(like, e.g., "mitochondrion") if a more narrow term (e.g., "mitochandrial membrane") 
can be found to describe the enrichment:

```{r}
goTestResults <- runTest( myGOdata, algorithm = "elim", statistic = "fisher" )

GenTable( myGOdata, goTestResults )
```

Inspect the table. Which results make sense, which don't? Try again for the other two
sub-ontologies, and for the down-regulated genes. Remember that gene set enrichments always
have to be taken with a grain of salt, but can be a good starting point for further
downstream analysis of a gene list.


# Session information

```{r}
sessionInfo()
```

# References