Remove run bias on MiSeq data?

[lynchde]

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]

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

[NextGenSeq]

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

[lynchde]

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]

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]

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.