SEQanswers

Go Back   SEQanswers > Bioinformatics > Bioinformatics



Similar Threads
Thread Thread Starter Forum Replies Last Post
Biological and technical replicates in expression analysis (DESeq) NicoBxl RNA Sequencing 0 08-22-2013 04:01 AM
Merging Mapped Reads from Technical Replicates Fernas RNA Sequencing 2 04-10-2013 02:48 PM
DESeq and technical replicates tamari Bioinformatics 0 10-17-2012 04:52 AM
Read runs and technical replicates scottdaniel RNA Sequencing 3 04-30-2012 11:49 AM
technical replicates uncorrelate with each other tujchl Epigenetics 4 05-26-2011 06:16 PM

Reply
 
Thread Tools
Old 07-03-2015, 03:16 PM   #1
friducha
Junior Member
 
Location: UK

Join Date: Jan 2015
Posts: 9
Default Why sum technical replicates instead of averaging (and rounding) for DESeq?

It is widely recommended to sum technical replicate samples for differential gene expression analysis.
I was wondering why this is the case, and not averaging the technical replicates into a single value for the individual?
friducha is offline   Reply With Quote
Old 07-03-2015, 07:03 PM   #2
Brian Bushnell
Super Moderator
 
Location: Walnut Creek, CA

Join Date: Jan 2014
Posts: 2,707
Default

I suppose that summing would give greater statistical power. If you have 10 replicates, each with 1 read mapped to some gene, then the sum would be 10 and the average 1. 1 event is a lot more likely to be noise than 10 events.

Aside from that, averaging and rounding would lose precision for no gain.
Brian Bushnell is offline   Reply With Quote
Old 07-05-2015, 02:48 PM   #3
bjackson
Junior Member
 
Location: Denver, CO

Join Date: May 2015
Posts: 6
Default

I just ended up asking a very similar question looking for guidance. When you say 'widely recommended' can you provided a paper or technical reference that says this? That would help me greatly.
bjackson is offline   Reply With Quote
Old 07-08-2015, 07:56 AM   #4
Michael Love
Senior Member
 
Location: Boston

Join Date: Jul 2013
Posts: 333
Default

There is a theoretical justification. The sum of Poisson RVs (random variables) is Poisson. Raw counts of uniquely assigned reads to genes are very close to Poisson distribution across technical replicates. And the statistical model includes Poisson RVs or RVs with higher dispersion (due to biological variation). So the sum is a good idea for summarizing technical replicates.

Note that the average of Poissons is not Poisson, for example, it has less variance than the mean. Suppose we take the mean of 5 Poisson RVs with lambda=10 and call this new thing X. The expected value will be 10,

> mean(replicate(1000, mean(rpois(5, lambda=10))))
[1] 9.9804

but the variance of X is now less than the mean:

> var(replicate(1000, mean(rpois(5, lambda=10))))
[1] 1.951687

This kind of a RV, a count which is under-dispersed, is not possible to model with the count-based methods.
Michael Love is offline   Reply With Quote
Old 09-25-2015, 02:40 PM   #5
stormin
Member
 
Location: US

Join Date: Aug 2014
Posts: 23
Default

Sorry to dig up the old post, I think my question is relevant to this discussion.

From practical point of view, technical replicates from the same RNA sample can be merged together into a single fastq file for mapping and subsequent counting. Is this the correct approach?

Alternatively, should mapping be done separately and counts added subsequently? Tophat is my current mapper, but please commend on whether this works with other mappers. Thanks
stormin is offline   Reply With Quote
Old 09-25-2015, 10:03 PM   #6
dpryan
Devon Ryan
 
Location: Freiburg, Germany

Join Date: Jul 2011
Posts: 3,479
Default

It doesn't really matter if you map and merge or merge and then map, you'll get essentially the same results regardless. This is true regardless of the aligner.
dpryan is offline   Reply With Quote
Reply

Tags
deseq, deseq2, rna-seq, rnaseq, sequencing

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 06:15 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO