[kmcarr]

Greetings,

It is very likely that an error or numerous errors occured during library preparation.

The demultiplexer that ships with CASAVA 1.8.2 is very stringent to avoid altogether contaminations like those you described above.

CASAVA 1.8.2 allows 0 mismatches in each index by default. This can be changed to 1 -- 1 is the maximum number of mismatches in any index for bar-coded data.


At our institution, we developed our own demultiplexer, called FastDemultiplexer, that allows more mismatches, which in turns increases yields and decreases clusters that are unclassified.

I hope you sort out this data confusion although the information you provided indicate erroneous library preparation.


Sébastien Boisvert
^^

Sébastien,

Technically the CASAVA pipeline will allow more mismatches (just pass a higher number with the --mistmatches parameter) but it will fail if there is a collision between barcodes caused by allowing multiple mismatches per index. For example:

TruSeq Index #18 == GTCCGC
TruSeq Index #19 == GTGAAA

Now suppose your encounter an index read which is GTCCAA. How do you resolve the conflict of this being #18 with the GC->AA at the end OR #19 with GA->CC in the middle. Unless you very carefully choose the mixture of barcodes you are likely to encounter these types of collisions when allowing more than one error per index read.

[phoss]

Could you please expand on what you mean by "Indexes with specific DNA composition patterns". We have been tearing our hair out recently because suddenly the quality of our index reads is horrible, leading to massive loss of sequence data because we can't determine the index sequence. This is happening on both our HiSeq2k and GAIIx. We have considered, and tentatively ruled out cluster density and degree of barcode diversity as the source of the problem. Any findings you could share would be greatly appreciated.

Hi kmcarr,
What we noticed during some of our multiplex-runs (single-end) was that the sequencing of the actual read was great... high quality scores, several million reads, etc. The indexes on the other hand were saturated with N's. Some indexes had the occasional N but as you know, CASAVA has a flag to handle such situations.
Nonetheless, we ran CASAVA demultiplexing on this dataset. The resultant CASAVA-build had very few reads in it simply due to the fact that the indexes are not mapped properly (too many Ns). What we saw is that samples that failed had indexes with a high T and/or G content. Whether it was index-sequencing error or these bases played a role in failed samples.. it's tough to say.
Have you looked at the thumbnails and found any anomalies?