Too many unpaired forward reads found by Trimmomatic
0
0
Entering edit mode
10 days ago

Hi, I am analyzing ATAC-Seq PE data using Trimmomatic-0.39,

TrimmomaticPE: Started with arguments:
 -threads 16 -phred33 ./data/R1.fastq.gz ./data/R2.fastq.gz R1_paired.fq.gz R1_unpaired.fq.gz R2_paired.fq.gz R2_unpaired.fq.gz ILLUMINACLIP:./NexteraPE-PE.fa:2:30:10 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36
Using PrefixPair: 'AGATGTGTATAAGAGACAG' and 'AGATGTGTATAAGAGACAG'
Using Long Clipping Sequence: 'GTCTCGTGGGCTCGGAGATGTGTATAAGAGACAG'
Using Long Clipping Sequence: 'TCGTCGGCAGCGTCAGATGTGTATAAGAGACAG'
Using Long Clipping Sequence: 'CTGTCTCTTATACACATCTCCGAGCCCACGAGAC'
Using Long Clipping Sequence: 'CTGTCTCTTATACACATCTGACGCTGCCGACGA'
ILLUMINACLIP: Using 1 prefix pairs, 4 forward/reverse sequences, 0 forward only sequences, 0 reverse only sequences
Input Read Pairs: 31710731 Both Surviving: 14986357 (47.26%) Forward Only Surviving: 16327631 (51.49%) Reverse Only Surviving: 48503 (0.15%) Dropped: 348240 (1.10%)
TrimmomaticPE: Completed successfully

As can be seen in the results, the amount of forward unpaired reads is overwhelmingly high. What can be the reason for that?

Thank you.

Trimmomatic • 340 views
ADD COMMENT
0
Entering edit mode

Interestingly, when I didn't provide the adapter file, the number of unpaired forward reads was significantly reduced:

TrimmomaticPE: Started with arguments:
 -threads 8 -phred33 ./data/R1.fastq.gz ./data/R2.fastq.gz R1_paired.fq.gz R1_unpaired.fq.gz R2_paired.fq.gz R2_unpaired.fq.gz ILLUMINACLIP:./NexteraPE-PE.fa:2:30:10 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36
java.io.FileNotFoundException: ./NexteraPE-PE.fa (No such file or directory)
        at java.base/java.io.FileInputStream.open0(Native Method)
        at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
        at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
        at org.usadellab.trimmomatic.fasta.FastaParser.parse(FastaParser.java:54)
        at org.usadellab.trimmomatic.trim.IlluminaClippingTrimmer.loadSequences(IlluminaClippingTrimmer.java:110)
        at org.usadellab.trimmomatic.trim.IlluminaClippingTrimmer.makeIlluminaClippingTrimmer(IlluminaClippingTrimmer.java:71)
        at org.usadellab.trimmomatic.trim.TrimmerFactory.makeTrimmer(TrimmerFactory.java:32)
        at org.usadellab.trimmomatic.Trimmomatic.createTrimmers(Trimmomatic.java:59)
        at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:552)
        at org.usadellab.trimmomatic.Trimmomatic.main(Trimmomatic.java:80)
Input Read Pairs: 31710731 Both Surviving: 30406417 (95.89%) Forward Only Surviving: 1198111 (3.78%) Reverse Only Surviving: 70414 (0.22%) Dropped: 35789 (0.11%)
TrimmomaticPE: Completed successfully

Is it indicating that I used the wrong adapter file? I applied fastqc on my raw data and noticed that they were Sanger / Illumina 1.9 encoding and contaminated with Nextera Transposase sequence, so I assumed I should use the adapter file NexteraPE-PE.fa found in Trimmomatic.

ADD REPLY
0
Entering edit mode

when I didn't provide the adapter file

Still see the file here ILLUMINACLIP:./NexteraPE-PE.fa:2:30:10, unless that is an empty file.

ADD REPLY
0
Entering edit mode

The first example used the adapter file NexteraPE-PE.fa, but it generated more than 50% unpaired data......

The content of NexteraPE-PE.fa is:

>PrefixNX/1
AGATGTGTATAAGAGACAG
>PrefixNX/2
AGATGTGTATAAGAGACAG
>Trans1
TCGTCGGCAGCGTCAGATGTGTATAAGAGACAG
>Trans1_rc
CTGTCTCTTATACACATCTGACGCTGCCGACGA
>Trans2
GTCTCGTGGGCTCGGAGATGTGTATAAGAGACAG
>Trans2_rc
CTGTCTCTTATACACATCTCCGAGCCCACGAGAC
ADD REPLY
0
Entering edit mode

Ideally you will know which adapters to use but if you don't then programs like fastp can auto-detect them. You could also use bbduk.sh with its included adapters.fa for scanning and trimming. You could also detect them using bbduk.shsee --> Identify adapter sequences for trimming from Illumina paired end fastq files

It is possible that the result first time around is correct i.e. you could be using the wrong file in second attempt and thus only a small fraction of reads (that may be similar by chance) are getting trimmed.

ADD REPLY
0
Entering edit mode

Using fastp, I found that the adapter sequence for the forward read is corresponding to Trans2_rc in the NexteraPE-PE.fa, while for the reverse read is matching Trans1_rc. Could that be the reason why the output of trimmomatic is weird?

ADD REPLY

Login before adding your answer.

Traffic: 2276 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6