Reads align in an RF orientation in Nextera paired-end sequencing?

[jmacrm91]

I am analysing Nextera paired-end sequencing data and have discovered that ~25% of the reads align in an RF orientation, but I'm not sure why? According to the biochemistry of the sample preparation there should only be FR orientated reads?

[Brian Bushnell]

There are tools out there that will incorrectly call read orientation if the insert size is shorter than read length. How, specifically, did you do preprocessing (such as adapter-trimming), mapping, and calculate the orientations?

Also, is this a Nextera fragment or LMP library? The LMP libraries can produce output in either orientation.

[jmacrm91]

I trimmed the adapters using Trimmomatic in PE mode using the Nextera-PE adapters provided. I then mapped the trimmed reads using Bowtie2, with max insert size set to 2000. I then removed PCR duplicates using Picard's MarkDuplicates. I then wanted to look at the insert distribution size and that's when Picard's CollectInsertSizeMetrics reported that I had both RF and FR orientated reads. If I plot a graph of the RF insert sizes, most of them are the size of my reads (~125) but I do still get a lot which are significanly bigger (~500-900bp). It's a bit odd that 75% map in the correct FR orientation, and 25% map in the RF orientation. At first I thought this may be to do with the tagmentation process used by the transposomes. The transposomes are dimers made up of two monomers, each of which has a sinle primer attached. The monomers are made by mixing them in a solution with 50% forward primers and 50% reverse primers. The monomers then dimerise and are used for tagmentation. That means that the 25% of the transposome dimers have two forward primers, 25% have two reverse and 50% have both the forward and reverse. The sample is from an ATAC-seq experiment, it does not have a circularised fragment step, so I don't think it is a LMP library, but a Nextera fragment

Commands used:

# Trimming
java -jar Trimmoamtic.jar PE \
-threads 1 \
sample_1.fastq \
sample_2.fastq \
sample_1P.fastq \
sample_1U.fastq \
sample_2P.fastq \
sample_2U.fastq \
ILLUMINACLIP:NexteraPE-PE.fa:2:30:10:1:true \
LEADING:20 \
TRAILING:20 \
SLIDINGWINDOW:4:15 \
MINLEN:15

# Mapping
bowtie2 -X 2000 \
-p 4 \
-x genome \
-1 sample_1P.fastq \
-2 sample_2P.fast \
-S sample.sam

# Remove PCR duplicates
java -Xmx2g -XX:ParallelGCThreads=4 -jar Picard.jar MarkDuplicates \
I=sample.sorted.bam \
O=sample.sorted.rmdup.bam \
M=sample.sorted.rmdup.pcrMetrics \
REMOVE_DUPLICATES=true \
ASSUME_SORTED=true \
VALIDATION_STRINGENCY=LENIENT

# Collect insert sizes
java -jar Picard.jar CollectInsertSizeMetrics \
I=sample.sorted.rmdup.bam \
O=sample_insertsize.metrics \
H=sample_insertsize.pdf \
VALIDATION_STRINGENCY=LENIENT

[roliwilhelm]

Interesting Question - If I find the time...

...I might try replicating what you've done using my own Nextera PE libraries. That would have an effect on how assemblers can be tailored for Nextera chemistry.

Thanks for the detailed response.

[Brian Bushnell]

I wrote a program for binning Nextera LMP libraries into LMP, short-fragment, unknown, and singleton sets. The usage is like this:

splitnextera.sh in=<file> out=<file> outf=<file> outu=<file> outs=<file>

It's part of the BBTools package.

[karencon]

wrong RF orientated reads in atac-seq bam file

I am analysing Nextera paired-end sequencing data and have discovered that ~25% of the reads align in an RF orientation, but I'm not sure why? According to the biochemistry of the sample preparation there should only be FR orientated reads?

We have had the same problem with our atac-seq (first time ever analysed it) and couldn't find any explanation or answer to this problem. Have you or anyone here found the solution/answer for it and could share with us please? Thank you in advance!

Karen