High % "N" in first 35bp using MultiQC

[hoytpr]

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/vct9szek097lrkl/Weird%20Per%20base%20N-content%20Jan%202019.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]

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

[hoytpr]

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

https://www.dropbox.com/s/ijb1ikhr9xahv1t/metrics.png?dl=0

[hoytpr]

The % NoCall looks a little weird:

https://www.dropbox.com/s/osm8higjbe93460/No-Calls.png?dl=0

[GW_OK]

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]

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