High % "N" in first 35bp using MultiQC

hoytpr · 01-07-2019, 10:26 AM

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.

GW_OK · 01-07-2019, 12:41 PM

What'd the metrics graphs (intensity, %base, %Q30, error rate) look like?

hoytpr · 01-07-2019, 12:54 PM

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

hoytpr · 01-07-2019, 01:03 PM

The % NoCall looks a little weird:

https://www.dropbox.com/s/osm8higjbe...Calls.png?dl=0

GW_OK · 01-08-2019, 07:59 AM

Might be due to the decrease in base diversity at the beginning of the reads. Maybe you've got some primer dimer in there?

hoytpr · 01-08-2019, 10:29 AM

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

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 08:25 AM
DEXSeq error in estimateDispersions: match.arg(start.method, c("log(y)", "mean"))	fpadilla	Bioinformatics	14	07-03-2013 03:11 PM
The position file formats ".clocs" and "_pos.txt"? Ist there any difference?	elgor	Illumina/Solexa	0	06-27-2011 08:55 AM
"Systems biology and administration" & "Genome generation: no engineering allowed"	seb567	Bioinformatics	0	05-25-2010 01:19 PM

01-07-2019, 10:26 AM	#1
hoytpr Member Location: Stillwater Join Date: Dec 2009 Posts: 62	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 10:34 AM. Reason: clarity

01-07-2019, 12:54 PM	#3
hoytpr Member Location: Stillwater Join Date: Dec 2009 Posts: 62	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 12:58 PM.

01-07-2019, 12:41 PM	#2
GW_OK Senior Member Location: Oklahoma Join Date: Sep 2009 Posts: 411	What'd the metrics graphs (intensity, %base, %Q30, error rate) look like?

01-07-2019, 01:03 PM	#4
hoytpr Member Location: Stillwater Join Date: Dec 2009 Posts: 62	The % NoCall looks a little weird: https://www.dropbox.com/s/osm8higjbe...Calls.png?dl=0

01-08-2019, 07:59 AM	#5
GW_OK Senior Member Location: Oklahoma Join Date: Sep 2009 Posts: 411	Might be due to the decrease in base diversity at the beginning of the reads. Maybe you've got some primer dimer in there?

01-08-2019, 10:29 AM	#6
hoytpr Member Location: Stillwater Join Date: Dec 2009 Posts: 62	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