I am analyzing RNA-seq data and I want to understand how to select the proper Trimmomatic parameters based on my FastQC report.
Which FastQC metrics indicate that I should use:
• ILLUMINACLIP
• SLIDINGWINDOW
• LEADING / TRAILING
• MINLEN
If possible, please explain why and when each parameter is used, and how to interpret FastQC warnings (adapter content, per-base quality, overrepresented sequences, etc.)
Your insight will be very helpful and highly appreciated.
file link: https://drive.google.com/drive/folders/1QT5NDqvaCwn7s7verT6e0UA-UhO96Axq?usp=drive_link
•
written
by
abdulmajeedkhattak1 •
This workflow is outdated, in my opinion. Also, adapter trimming is rarely critical, particularly in RNA-seq applications. I would use fastp with standard parameters, then summarize the output with multiqc if analyzing multiple datasets. If the adapter content is still detectable, use a second round of trimming with cutadapt or trimmgalore using the specific adapter sequences.
Dear Michael Dondrup, Thank you for your accurate advice and valuable suggestion. I am in the process of learning Trimmomatic, and I plan to continue with fastp, MultiQC, and Cutadapt to further enhance my workflow.
@Michael's points are valid but there is no downside to doing trimming and for using trimmomatic (or any other similar program). Scanning/trimming ensures that there is no extraneous sequence remaining in data. That becomes critical, if you ever decide to do any de novo assembly.
These parameters are explained in the trimmomatic manual: http://www.usadellab.org/cms/uploads/supplementary/Trimmomatic/TrimmomaticManual_V0.32.pdf
You will need to provide the adapter sequences for ILLUMINACLIP. You will rarely need to use LEADING/TRAILING (see https://sequencing.qcfail.com/articles/positional-sequence-bias-in-random-primed-libraries/ ). With current sequencing data the quality should be good that you should again not need to use MINLEN or SLIDINGWINDOW to ensure data remains above a certain quality.
Some of these parameters were relevant in early days of sequencing (and remain so for old data) when overall quality of data was not as good as it generally is today.
Another comment I will make is that the defaults by trimmomatic behave very differently from those in fastp.
The two tools can produce radically different outcomes. It relates to the direction in which the average window moves. It can move from the start to the back, or from the end to the back. If there are subwindows early on where the average drops, one approach may cut more data than the other.
I recall a frantic email from a student:
Basically, any quality trimming that we perform loses > 90% of the reads… even if we don’t do any trimming of the forward or reverse ends and set a quality filter at Phred score 20, we’re down to fewer than 1000 reads per sample. I’ve tested this with dada2 and Trimmomatic. This is happening with all four datasets from the Core. I haven’t run into this before, so I’m hoping you can help us figure out the discrepancy between the sequencing quality reports and what we’re seeing when we start the filtering process.
It was quite head-scratching to troubleshoot. In the end, it came down to fastp parameters such as --cut_tail vs --cut_right
Log in to answer this question.
