Remove run bias on MiSeq data?

lynchde · 07-21-2014, 07:14 AM

Hello.
Our lab previously used 454 pyrosequencing to analyse 16S rDNA data. We have recently moved to using MiSeq (we get more samples done in one run). However we have come across a problem. There is a large discrepancy between one MiSeq run and the next.
We have tried to rarefy the data to minimize this difference, but it has made little or no difference.
Has anyone seen such a run bias? Can anyone suggest any programs or anything that might be able to reduce it?

Thank you in advance!

Bukowski · 07-21-2014, 10:05 AM

It would help if you would describe what kind of discrepancy you are seeing.

NextGenSeq · 07-22-2014, 06:48 AM

I doubt it's the MiSeq. It's more likely your library prep or PCR.

lynchde · 07-23-2014, 01:53 AM

The discrepancy is this. We've got a group of samples in one run that we expect to cluster together, and they do. They are also expected to cluster with a group of samples on a second run, but this is not the case.
There are a few groups like that, so it is not just a case of chance for this one group being different to what we expected. Samples separate by MiSeq runs where they are expected to cluster. (PCoAs, spearman distance between samples).

I'm inclined to agree about the PCR/library prep. But do you know of any way to adjust for this in the reads that are returned?

GenoMax · 07-23-2014, 02:57 AM

Were these libraries done on separate days by different individuals? Were they run on the same sequencer/reagent lot/processed with same version of MCS? Is there anything strange about coverage/GC content/distribution of nucleotides across these runs?

lynchde · 07-23-2014, 03:10 AM

Were these libraries done on separate days
Libraries were done on separate days, but also in parts. There are ~150 samples in one library. So they were done in batches based on barcoded primers.

by different individuals?
All were done by the same individual.

Were they run on the SAME sequencer/reagent lot/processed with same version of MCS?
One library was run on a different sequencer, but 3 other libraries were run on the same sequencer, and they still show differences. I can't say whether the reagent lot is the same or not, but the same versions of everything were used.

Is there anything strange about coverage/GC content/distribution of nucleotides across these runs?
The problem is that these are 16S rDNA libraries, so the coverage/GC content/distributions will all report errors with FASTQC but are still within expected ranges.

What was very unusual was that the quality wasn't great on all runs, and particularly poor for the reverse reads. We used the same parameters for quality filtering on all runs, so much of the poor data was removed. (We used FLASH to join overlapping forward & reverse reads, and split_libraries_fastq.py from the QIIME software with quality filtering).

I can see where problems could have been introduced: PCRs in batches, libraries done separately, 2 different machines for 1 run versus the other 3. But given that this is MiSeq data, we can't really afford to repeat too many samples. So I'm hoping for some bioinformatical fixes.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Primerdimer/Short Product Bias on the MiSeq	Vinz	Illumina/Solexa	3	02-21-2014 04:03 PM
MiSeq stopped run	yaximik	Illumina/Solexa	20	03-18-2013 07:10 AM
How much PhiX in MiSeq run?	thdybwf	Illumina/Solexa	1	11-26-2012 03:01 AM
Worst MiSeq Run ever?	pmiguel	Illumina/Solexa	0	04-30-2012 04:54 AM
Homopolymer run errors, polyA bias	sulfobus	454 Pyrosequencing	6	04-09-2010 04:15 AM

07-21-2014, 07:14 AM	#1
lynchde Junior Member Location: Ireland Join Date: Oct 2011 Posts: 6	Remove run bias on MiSeq data? Hello. Our lab previously used 454 pyrosequencing to analyse 16S rDNA data. We have recently moved to using MiSeq (we get more samples done in one run). However we have come across a problem. There is a large discrepancy between one MiSeq run and the next. We have tried to rarefy the data to minimize this difference, but it has made little or no difference. Has anyone seen such a run bias? Can anyone suggest any programs or anything that might be able to reduce it? Thank you in advance!

07-21-2014, 10:05 AM	#2
Bukowski Senior Member Location: UK Join Date: Jan 2010 Posts: 390	It would help if you would describe what kind of discrepancy you are seeing.

07-22-2014, 06:48 AM	#3
NextGenSeq Senior Member Location: USA Join Date: Apr 2009 Posts: 482	I doubt it's the MiSeq. It's more likely your library prep or PCR.

07-23-2014, 01:53 AM	#4
lynchde Junior Member Location: Ireland Join Date: Oct 2011 Posts: 6	The discrepancy is this. We've got a group of samples in one run that we expect to cluster together, and they do. They are also expected to cluster with a group of samples on a second run, but this is not the case. There are a few groups like that, so it is not just a case of chance for this one group being different to what we expected. Samples separate by MiSeq runs where they are expected to cluster. (PCoAs, spearman distance between samples). I'm inclined to agree about the PCR/library prep. But do you know of any way to adjust for this in the reads that are returned?

07-23-2014, 02:57 AM	#5
GenoMax Senior Member Location: East Coast USA Join Date: Feb 2008 Posts: 7,091	Were these libraries done on separate days by different individuals? Were they run on the same sequencer/reagent lot/processed with same version of MCS? Is there anything strange about coverage/GC content/distribution of nucleotides across these runs?

07-23-2014, 03:10 AM	#6
lynchde Junior Member Location: Ireland Join Date: Oct 2011 Posts: 6	Were these libraries done on separate days Libraries were done on separate days, but also in parts. There are ~150 samples in one library. So they were done in batches based on barcoded primers. by different individuals? All were done by the same individual. Were they run on the SAME sequencer/reagent lot/processed with same version of MCS? One library was run on a different sequencer, but 3 other libraries were run on the same sequencer, and they still show differences. I can't say whether the reagent lot is the same or not, but the same versions of everything were used. Is there anything strange about coverage/GC content/distribution of nucleotides across these runs? The problem is that these are 16S rDNA libraries, so the coverage/GC content/distributions will all report errors with FASTQC but are still within expected ranges. What was very unusual was that the quality wasn't great on all runs, and particularly poor for the reverse reads. We used the same parameters for quality filtering on all runs, so much of the poor data was removed. (We used FLASH to join overlapping forward & reverse reads, and split_libraries_fastq.py from the QIIME software with quality filtering). I can see where problems could have been introduced: PCRs in batches, libraries done separately, 2 different machines for 1 run versus the other 3. But given that this is MiSeq data, we can't really afford to repeat too many samples. So I'm hoping for some bioinformatical fixes.