Too many unpaired forward reads found by Trimmomatic

Question

[SilhouetteQ]

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.

[SilhouetteQ]

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.

[GenoMax]

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.

[SilhouetteQ]

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

[GenoMax]

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.

[SilhouetteQ]

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?