<p>If they're truly technical replicates, then <strike>there's no way to model them using DESeq2</strike>*, as you've alluded to with the <code>collapseReplicates</code> function. DESeq2/ Mike Love's general recommendation with <code>collapseReplicates</code> is to just add the reads together for technical replicates. </p>

<p>If you want to model them instead of collapsing them down, you can <code>voom</code> transform your data and follow an example similar to section 11.3 in the <a href="https://www.bioconductor.org/packages/devel/bioc/vignettes/limma/inst/doc/usersguide.pdf" rel="noreferrer">Limma users guide</a>.</p>

<p><strong>(Code example from 11.3):</strong></p>

<p><em>Design</em></p>

<pre><code>| FileName  | Cy3   | Cy5  |
| --------- |:-----:| ----:|
| File1     | wt1   | mu1  |
| File2     | wt1   | mu1  |
| File3     | wt2   | mu2  |
| File4     | wt2   | mu2  |
</code></pre>

<p><em>Example</em></p>

<pre><code>&gt; biolrep &lt;- c(1, 1, 2, 2)
&gt; corfit &lt;- duplicateCorrelation(MA, ndups = 1, block = biolrep)
&gt; fit &lt;- lmFit(MA, block = biolrep, cor = corfit$consensus)
&gt; fit &lt;- eBayes(fit)
&gt; topTable(fit, adjust = "BH")
</code></pre>

<p>*Edit: As @Devon Ryan mentions, you can design a paired model in <code>DESeq2</code>, but beware of making this full rank. </p>

CC BY-SA 3.0
2017-05-25T11:45:06.670Z
This answer makes me think that we need table layout support on this website: tables of features/counts/… will be extremely common here.
Konrad Rudolph
CC BY-SA 3.0
2017-05-25T12:11:29.007Z
@KonradRudolph - Agreed, It was a shame when I found out that markdown tables weren't supported!
A_Skelton73
CC BY-SA 3.0
2017-05-24T11:09:19.483Z
2017-05-25T10:04:02.870Z
2017-05-25T10:04:02.870Z
A_Skelton73
<p>Practically speaking, there's no way to include the technical replicates in that design (in DESeq2 at least). Your concern regarding inflating the power is exactly correct and the only way to combat that would be to add a pairing factor like one might do with case-control or tumor-normal studies. That is, something like:</p>

<pre><code>  group libraryPrep sample
1    WT           A      1
2    WT           B      1
3   MUT           A      2
4   MUT           B      2
5    WT           A      3
6    WT           B      3
7   MUT           A      4
8   MUT           B      4
</code></pre>

<p>Here <code>sample</code> pairs the technical replicates together. However this ends up either being rank deficient or in the end not more informative.</p>

CC BY-SA 3.0
2017-05-24T10:20:25.597Z
2017-05-24T10:20:25.597Z
Devon Ryan
<p>I’d normally use <code>collapseReplicates</code> (or do the collapsing upstream) to handle technical replicates.</p>

<p>However, in my current RNA-seq experimental design, samples were sequenced twice using different library preparation protocols, leading to marked differences in the resulting count estimates (in fact, the choice of different protocol explains most of the variance in the bulk data according to PCA). I would therefore like to model these differences by adding them as a covariate to the DESeq2 model.</p>

<p>I <em>thought</em> I could just add another factor to the design formula, equivalent to <a href="https://www.bioconductor.org/packages/devel/bioc/vignettes/DESeq2/inst/doc/DESeq2.html#multi-factor-designs" rel="noreferrer">the “pasilla” example in the DESeq2 vignette</a>, which adds the factor <code>type</code> for the library type (single-end vs paired-end). However, the <a href="http://bioconductor.org/packages/release/data/experiment/vignettes/pasilla/inst/doc/create_objects.html" rel="noreferrer">pasilla vignette</a> states that these different libraries are actually independent <em>biological</em> replicates, not technical replicates as I had previously assumed.</p>

<p>I’m now concerned that having technical replicates in the design might artificially inflate the power. Can the design be salvaged?</p>

<p>It’s worth noting that we <em>also</em> have biological replicates, and a full rank design; i.e. every combination of treatment and library prep, with biological replicates.</p>

<rna-seq><deseq2>
Can I model technical replicates in DESeq2?
# Can I model technical replicates in DESeq2?

(Asked by: username_0 on 2017-05-24)

I’d normally use `collapseReplicates` (or do the collapsing upstream) to handle technical replicates.

However, in my current RNA-seq experimental design, samples were sequenced twice using different library preparation protocols, leading to marked differences in the resulting count estimates (in fact, the choice of different protocol explains most of the variance in the bulk data according to PCA). I would therefore like to model these differences by adding them as a covariate to the DESeq2 model.

I *thought* I could just add another factor to the design formula, equivalent to [the “pasilla” example in the DESeq2 vignette](https://www.bioconductor.org/packages/devel/bioc/vignettes/DESeq2/inst/doc/DESeq2.html#multi-factor-designs), which adds the factor `type` for the library type (single-end vs paired-end). However, the [pasilla vignette](http://bioconductor.org/packages/release/data/experiment/vignettes/pasilla/inst/doc/create_objects.html) states that these different libraries are actually independent *biological* replicates, not technical replicates as I had previously assumed.

I’m now concerned that having technical replicates in the design might artificially inflate the power. Can the design be salvaged?

It’s worth noting that we *also* have biological replicates, and a full rank design; i.e. every combination of treatment and library prep, with biological replicates.

**Tags:** rna-seq, deseq2

---

## 2 answers

### Answer by username_1 on 2017-05-24. Score: 6

If they're truly technical replicates, then there's no way to model them using DESeq2*, as you've alluded to with the collapseReplicates function. DESeq2/ Mike Love's general recommendation with collapseReplicates is to just add the reads together for technical replicates. 
If you want to model them instead of collapsing them down, you can voom transform your data and follow an example similar to section 11.3 in the Limma users guide.
(Code example from 11.3):
Design
| FileName  | Cy3   | Cy5  |
| --------- |:-----:| ----:|
| File1     | wt1   | mu1  |
| File2     | wt1   | mu1  |
| File3     | wt2   | mu2  |
| File4     | wt2   | mu2  |

Example
> biolrep <- c(1, 1, 2, 2)
> corfit <- duplicateCorrelation(MA, ndups = 1, block = biolrep)
> fit <- lmFit(MA, block = biolrep, cor = corfit$consensus)
> fit <- eBayes(fit)
> topTable(fit, adjust = "BH")

*Edit: As @Devon Ryan mentions, you can design a paired model in DESeq2, but beware of making this full rank.

> **Comments:**
> **username_0**: This answer makes me think that we need table layout support on this website: tables of features/counts/… will be extremely common here.  
> **username_1**: @KonradRudolph - Agreed, It was a shame when I found out that markdown tables weren't supported!  

---

### Answer by username_2 on 2017-05-24. Score: 5

Practically speaking, there's no way to include the technical replicates in that design (in DESeq2 at least). Your concern regarding inflating the power is exactly correct and the only way to combat that would be to add a pairing factor like one might do with case-control or tumor-normal studies. That is, something like:
  group libraryPrep sample
1    WT           A      1
2    WT           B      1
3   MUT           A      2
4   MUT           B      2
5    WT           A      3
6    WT           B      3
7   MUT           A      4
8   MUT           B      4

Here sample pairs the technical replicates together. However this ends up either being rank deficient or in the end not more informative.


---

