[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?

[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.

[seb567]

I also just had an issue with the index read on two lanes, it looks like some tiles lost to the bottom middle swath problem. It didn't happen in all cycles but I had many more unassigned reads in these two lanes than I should.

With CASAVA 1.8.2 the mismatches allowed for the index read by default is 0. Does anyone think that setting --mismatches 1 would allow less conservative index sorting?

Hi,

Yes, --mismatches 1 is less conservative as it allows 1 mismatch in the first index and 0 in the second, if any.

With CASAVA 1.8.2, the correct invocation is --mismatches 1,1

Using --mismatches 1 is equivalent to using --mismatches 1,0.

See these scripts here.

The default is --mismatches 0,0 which is the same as --mismatches 0


Sébastien Boisvert

[seb567]

Hi, there.
We've have experienced puzzling troubles when we tried to analyze a multiplexed sequencing on Illumina HiSeq platform. Something is wrong with our output results, considering that, we had 7 multiplex libraries together and when we tried Cassava demultiplexing we found "contamination" of results.
I mean that reads expected to belong, i.e., to library #1 are spread everywhere, with nonsense relationships.
It's like a big mosaic of untidy correspondences. We tried to change demultiplexing parameters, without any improvement.
What do you think? Where is the key? In bioinformatics, or worse, it is possible that some biological contamination of reagents occurred? That index-seq primers were accidentally mixed?
It seems far option, but if not what else?

Please, help...

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
^^

[kmcarr]

Hi uattsoancrik,
What I had meant to say in my prior post was whether you see specific DNA patterns in the indexes which map to 'contaminated' samples.

In response to your question: We had the following scenario: Indexes with specific DNA composition patterns yielded high percentage of low-quality reads, while on the contrary, indexes with differing DNA composition yielded high percentage of high-quality reads. What is interesting though is that these if these indexes were found on other lanes, such samples also ended up having low-quality reads.
We debugged the above scenario and reached a number of possible of conclusions such as expired reagents / kit, too-much/to little sample, sequencing of the index, even oil on the slide (which I don't think the HiSeq has; only the GAII if I'm no mistaken).

Hopefully this was helpful nonetheless.
Best,

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.

[phoss]

Hi uattsoancrik,
What I had meant to say in my prior post was whether you see specific DNA patterns in the indexes which map to 'contaminated' samples.

In response to your question: We had the following scenario: Indexes with specific DNA composition patterns yielded high percentage of low-quality reads, while on the contrary, indexes with differing DNA composition yielded high percentage of high-quality reads. What is interesting though is that these if these indexes were found on other lanes, such samples also ended up having low-quality reads.
We debugged the above scenario and reached a number of possible of conclusions such as expired reagents / kit, too-much/to little sample, sequencing of the index, even oil on the slide (which I don't think the HiSeq has; only the GAII if I'm no mistaken).

Hopefully this was helpful nonetheless.
Best,

[uattsoancrik]

Hi phoss,
as I said before, our indexes came from Illumina Index Sequencing Primers package A (6 out of 7) and B (1 out of 7). So, studied to be used together as you should expect from a commercial kit.

I'm curious, too, how did you manage your problem, and if you understood what was wrong in your case. Please, let me know. It could be useful discussion. Thx.

[phoss]

Hi uattsoancrik,
We had a similar problem to your original post; saw such results with some multiplexed samples on the GAIIx.
Just curious: the contaminated samples you mentioned originally... are the indexes for these respective samples similar?
Best,

[uattsoancrik]

In addition I was thinking that our Index Sequencing Primers were from two different sources. 6 out of 7 were from package A and the other from package B. Do you think this could interfere with results? In which way? And why Illumina released two different versions? Does anybody know what's the difference?

[epistatic]

Great point, I need to see what indexes they have and likely won't waste my time. The BMS issue is annoying enough without it hitting the index read.

I don't have the indexes you mention in the 24 index set and think the Illumina indexes all tolerate at least one-mismatch.

[mnkyboy]

I have played with changing --mismatches to 1 and have not seen a huge gain. Also two of the indexes are not compatible if you do this. If you use GACGAC and CACGAT with mismatch 1 it will fail, they become GACGAT.

I learned this the hard way.

[epistatic]

I also just had an issue with the index read on two lanes, it looks like some tiles lost to the bottom middle swath problem. It didn't happen in all cycles but I had many more unassigned reads in these two lanes than I should.

With CASAVA 1.8.2 the mismatches allowed for the index read by default is 0. Does anyone think that setting --mismatches 1 would allow less conservative index sorting?

[amitm]

hi westerman,
you are right. The --use-bases-mask parameter can allow less than six bases as index and some reads can be salvaged if index base quality has been the problem.
thanks for correcting.

[westerman]

What demultiplexing parameters you changed? Apart from allowing one mismatch in the index sequence (default 0), I don't remember any other parameter that would alter the demultiplexing output.

You can use less than 6-base indexes. The --use-base parameter is used for this as well as changing the indexes in your sample sheet.

Not that I think it will make any difference in this case. But I have used the above trick when we have had really poor results for some of the index positions.

[twaddlac]

We experienced this in my lab. We traced it back to the library prep - we mapped the barcodes to their physical location on the 96-well plate to see if there was any cross contamination and there sure was. I would try something like that before indulging too much in the forensics of bioinformatics. It will at least give you an idea of how to assess your data once you find out the source of contamination.

I hope that helps!