<p>The command where you trim with adapters and by quality is perfectly fine. That FastQC isn't perfectly happy is expected. It's a tool made for whole genome sequencing QC, you SHOULD see a number of "fail"s with any RNA-seq protocol. Steps that should always fail in RNA-seq:</p>

<ul>
<li>per-base sequence content (there's "random priming" performed that isn't completely random, so the first ~8 bases show a typical bias pattern).</li>
<li>per-sequence GC content (particularly in sRNA-seq you're enriching for a subset of genes, they won't have some nice GC distribution and that's perfectly OK).</li>
<li>Sequence duplication level (if this doesn't fail then everything is uniformly expressed...which would be quite unlikely)</li>
<li>Overrepresented sequences (as above, though this will be worse for sRNA-seq since reads will often cover the entire transcript, so there's even less sequence diversity)</li>
</ul>

CC BY-SA 4.0
2019-07-16T18:47:53.850Z
Thank you for your answer. I expected FastQC not being happy with the sequence duplication level and overrepresented sequences, but I couldn't explain the other two. What about the "per tile sequence quality"? Did adapters inflated artificially the quality of those tiles? Should I do something about that (filter those reads out...) or can I leave them as is?
LinuxBlanket
CC BY-SA 4.0
2019-07-16T21:59:03.490Z
Yes, it appears that the adapters inflated quality a bit. Don't worry about failed clusters, there's no point in trimming that minor an issue off.
Devon Ryan
CC BY-SA 4.0
2019-07-14T19:35:12.333Z
2019-07-14T19:35:12.333Z
Devon Ryan
<p>I'm having some problems with finding the right parameters to trim my small RNA Illumina reads (51 nt long) with Trimmomatic.</p>

<p>Before trimming, one of the samples (21M reads) looks like this:</p>

<p><a href="https://i.sstatic.net/powRQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/powRQ.png" alt="enter image description here"></a></p>

<p>So for my understanding, it's quite good and the last two issues can be easily solved with adapter trimming.</p>

<p>I then tried to trim it with the command </p>

<pre><code>java -jar /opt/Trimmomatic-0.38/trimmomatic-0.38.jar SE -threads 24 -phred33 FemaleMito3.fastq FemaleMito3_trimmed.fastq ILLUMINACLIP:adapters.ultimate.fa:2:30:10 AVGQUAL:25 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:18
</code></pre>

<p>but I got the following result:</p>

<p><a href="https://i.sstatic.net/eF2y0.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/eF2y0.png" alt="enter image description here"></a></p>

<p>So now I have a problem with the sequence quality per tile (why?), an overall drop of the quality at the end of the reads and a warning with the sequence length distribution.</p>

<p>Then I tried trimming just the adapters with this command: </p>

<pre><code>java -jar /opt/Trimmomatic-0.38/trimmomatic-0.38.jar SE -threads 24 -phred33 FemaleMito1.fastq FemaleMito1_noadapters.fastq ILLUMINACLIP:adapters.ultimate.fa:2:30:10 AVGQUAL:25
</code></pre>

<p>but again I get some new issues:</p>

<p><a href="https://i.sstatic.net/zlNDJ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/zlNDJ.png" alt="enter image description here"></a></p>

<p>Again the per tile sequence quality issue, and now a warning about the GC content.</p>

<p>I didn't find anywhere some precise instruction on how to trim a small RNA 
library with Trimmomatic. <strong>How should I properly trim my small RNA library with Trimmomatic?</strong></p>

CC BY-SA 4.0
2019-07-16T13:30:04.787Z
Relevant: https://bioinformatics.stackexchange.com/a/6788/96.
Daniel Standage
<rna-seq><transcriptome><trimming><data-preprocessing>
What are the right parameters to trim a small RNA transcriptome with trimmomatic?
# What are the right parameters to trim a small RNA transcriptome with trimmomatic?

(Asked by: username_0 on 2019-07-13)

I'm having some problems with finding the right parameters to trim my small RNA Illumina reads (51 nt long) with Trimmomatic.
Before trimming, one of the samples (21M reads) looks like this:

So for my understanding, it's quite good and the last two issues can be easily solved with adapter trimming.
I then tried to trim it with the command 
java -jar /opt/Trimmomatic-0.38/trimmomatic-0.38.jar SE -threads 24 -phred33 FemaleMito3.fastq FemaleMito3_trimmed.fastq ILLUMINACLIP:adapters.ultimate.fa:2:30:10 AVGQUAL:25 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:18

but I got the following result:

So now I have a problem with the sequence quality per tile (why?), an overall drop of the quality at the end of the reads and a warning with the sequence length distribution.
Then I tried trimming just the adapters with this command: 
java -jar /opt/Trimmomatic-0.38/trimmomatic-0.38.jar SE -threads 24 -phred33 FemaleMito1.fastq FemaleMito1_noadapters.fastq ILLUMINACLIP:adapters.ultimate.fa:2:30:10 AVGQUAL:25

but again I get some new issues:

Again the per tile sequence quality issue, and now a warning about the GC content.
I didn't find anywhere some precise instruction on how to trim a small RNA 
library with Trimmomatic. How should I properly trim my small RNA library with Trimmomatic?

**Tags:** rna-seq, transcriptome, trimming, data-preprocessing
> **Comments:**
> **username_1**: Relevant: https://bioinformatics.stackexchange.com/a/6788/96.  

---

## 1 answers

### Answer by username_2 on 2019-07-14. Score: 3 | Accepted answer

The command where you trim with adapters and by quality is perfectly fine. That FastQC isn't perfectly happy is expected. It's a tool made for whole genome sequencing QC, you SHOULD see a number of "fail"s with any RNA-seq protocol. Steps that should always fail in RNA-seq:

* per-base sequence content (there's "random priming" performed that isn't completely random, so the first ~8 bases show a typical bias pattern).
* per-sequence GC content (particularly in sRNA-seq you're enriching for a subset of genes, they won't have some nice GC distribution and that's perfectly OK).
* Sequence duplication level (if this doesn't fail then everything is uniformly expressed...which would be quite unlikely)
* Overrepresented sequences (as above, though this will be worse for sRNA-seq since reads will often cover the entire transcript, so there's even less sequence diversity)

> **Comments:**
> **username_0**: Thank you for your answer. I expected FastQC not being happy with the sequence duplication level and overrepresented sequences, but I couldn't explain the other two. What about the "per tile sequence quality"? Did adapters inflated artificially the quality of those tiles? Should I do something about that (filter those reads out...) or can I leave them as is?  
> **username_2**: Yes, it appears that the adapters inflated quality a bit. Don't worry about failed clusters, there's no point in trimming that minor an issue off.  

---

