SEQanswers

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



Similar Threads
Thread Thread Starter Forum Replies Last Post
MiSeq gDNA reads still fail "Kmer content" and "per base seq content" after trimming" ysnapus Illumina/Solexa 4 11-12-2014 07:25 AM
DEXSeq error in estimateDispersions: match.arg(start.method, c("log(y)", "mean")) fpadilla Bioinformatics 14 07-03-2013 02:11 PM
The position file formats ".clocs" and "_pos.txt"? Ist there any difference? elgor Illumina/Solexa 0 06-27-2011 07:55 AM
"Systems biology and administration" & "Genome generation: no engineering allowed" seb567 Bioinformatics 0 05-25-2010 12:19 PM

Reply
 
Thread Tools
Old 01-07-2019, 09:26 AM   #1
hoytpr
Member
 
Location: Stillwater

Join Date: Dec 2009
Posts: 57
Default High % "N" in first 35bp using MultiQC

Hi all,
Just did some sequencing for a client and got a little odd plot using MultiQC for the "FastQ per base N-Content". It looks like the first 35 bp had problems with "N" then suddenly stopped. The percentage isn't high, but I don't understand what happened. Using trimmomatic removed these which appeared to be runs of "N". Anyone seen something like this before, or have an explanation for this?

https://www.dropbox.com/s/vct9szek09...02019.png?dl=0

Thanks,
-pete
Edit: We made these libraries using KAPA tagmentation kits, and there were no bad tiles (none) using FastQC.

Last edited by hoytpr; 01-07-2019 at 09:34 AM. Reason: clarity
hoytpr is offline   Reply With Quote
Old 01-07-2019, 11:41 AM   #2
GW_OK
Senior Member
 
Location: Oklahoma

Join Date: Sep 2009
Posts: 408
Default

What'd the metrics graphs (intensity, %base, %Q30, error rate) look like?
GW_OK is offline   Reply With Quote
Old 01-07-2019, 11:54 AM   #3
hoytpr
Member
 
Location: Stillwater

Join Date: Dec 2009
Posts: 57
Default

Most everything looked okay. There is a little glitch at 35bp in the data by Cycle Error rate

https://www.dropbox.com/s/ijb1ikhr9x...trics.png?dl=0

Last edited by hoytpr; 01-07-2019 at 11:58 AM.
hoytpr is offline   Reply With Quote
Old 01-07-2019, 12:03 PM   #4
hoytpr
Member
 
Location: Stillwater

Join Date: Dec 2009
Posts: 57
Default

The % NoCall looks a little weird:

https://www.dropbox.com/s/osm8higjbe...Calls.png?dl=0
hoytpr is offline   Reply With Quote
Old 01-08-2019, 06:59 AM   #5
GW_OK
Senior Member
 
Location: Oklahoma

Join Date: Sep 2009
Posts: 408
Default

Might be due to the decrease in base diversity at the beginning of the reads. Maybe you've got some primer dimer in there?
GW_OK is offline   Reply With Quote
Old 01-08-2019, 09:29 AM   #6
hoytpr
Member
 
Location: Stillwater

Join Date: Dec 2009
Posts: 57
Default

Must just be primer dimers. I talked with Illumina today and they looked at it. Basically said it's normal for a NextSeq to have these runs of "N" (they call "N-masking when multiplexing") when primer-dimers are present, and gave me a couple flags for bcl2fastq to get rid of them:

--minimum-trimmed-read-length 0
--mask-short-adapter-reads 0

Trimmomatic also does a good job of cleaning them up.

java -jar trimmomatic-0.35.jar SE -phred33 input.fq.gz output.fq.gz ILLUMINACLIP:TruSeq3-SE:2:30:10 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36
hoytpr is offline   Reply With Quote
Reply

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 10:18 PM.


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