Go Back   SEQanswers > Sequencing Technologies/Companies > Illumina/Solexa

Similar Threads
Thread Thread Starter Forum Replies Last Post
human contamination for mouse RNAseq samples cassiemin RNA Sequencing 2 06-21-2018 02:23 PM
index contamination in multiplexed run btb Illumina/Solexa 19 12-03-2014 05:35 PM
truseq DNA LS library preparation --- index adaptor issue weihuameng Sample Prep / Library Generation 2 09-03-2014 10:19 PM
Contamination between samples run on the same lane MLog Illumina/Solexa 4 12-08-2013 05:42 PM
GATK Unknown index type value808519985 quoclinh Bioinformatics 1 05-04-2011 11:30 AM

Thread Tools
Old 07-13-2018, 06:41 AM   #1
Junior Member
Location: Vienna

Join Date: Jan 2018
Posts: 2
Default Unknown index contamination in DNA library, carried into demultiplexed samples

Hello everyone,

I have encountered a rather strange contamination in our DNA libraries and would be thankful for help in finding the source, the proper way to trim it and advice on how to avoid it in the future.

Our plant sample DNA are prepared in-house following a modified KAPA protocol with P5-P7 indexes (that we mix ourselves; corresponsing to Illumina adapters) and AMPure beads. We use dual-indexing attached in a PCR step (rather short with 8 cycles). Our indexes are 8bp long corresponding to TruSeq. Prior to pooling all samples are size-selected to remove fragments <150bp, hence supposedly removing all traces of adapter dimer. Samples were pooled and sent to sequencing center where they were sequenced on a HiSeqV4 PE125. A spike-in from another user was present.

According to the fastqc report, on read1 the full library seems to include about 6 million reads of an unknown source, not similar to any index that we used, not to the index reported from the other user nor to published DNA sequences from Illumina, but it does 'look like' an artifact:
It doesn't blast to any known plant sequences (seems to blast to some human sequence but with a low match, could be adapter someone else left in...). No contamination is present on read2. See attached fastqc screenshot.

The truly inexplicable part is that after successfully demultiplexing (using deML) those 'contaminant' reads are present in all separate sample files in similar numbers (example fastqc report attached), comprising 20% of the reads for some samples! I cannot understand this behavior and cannot figure out whether I'm seeing a PCR artifact, another user's index or something else.
In addition, trimming those reads using Trimmomatic gave bad results - I added the contaminant sequence to Trimmomatic's adapter file and lost almost 40% of the reads for many samples.

Any hint to direct me in bioinformatic forensics would be very much welcome.
Attached Images
File Type: jpg fastqc_whole_lib.jpg (90.9 KB, 9 views)
File Type: jpg fastqc_single_demultiplexed.jpg (86.2 KB, 3 views)

Last edited by gyardeni; 07-13-2018 at 08:45 AM.
gyardeni is offline   Reply With Quote
Old 07-18-2018, 03:39 AM   #2
Senior Member
Location: Purdue University, West Lafayette, Indiana

Join Date: Aug 2008
Posts: 2,317

No idea. Maybe take a look at them untrimmed to see what adapter type is carrying the insert.

pmiguel is offline   Reply With Quote
Old 07-18-2018, 04:02 AM   #3
Junior Member
Location: Vienna

Join Date: Jan 2018
Posts: 2

Hi Phillip,

Thanks for the reply. Since posting I actually took a look at the demultiplexing method, since it seemed like strange sequences ended up in the demultiplexed files. It turned out to be the behavior of samtools - when using the -r command to separate by RG field all the lines that don't have that field end up in the file, too.
I opened an issue and it seems that're planning to fix it (follow here:
gyardeni is offline   Reply With Quote

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 05:03 AM.

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