<ol>
<li><p>Ignore the overrepresented sequences. The counts for these that you show is so low (10, 11) that it is irrelevant.</p>
</li>
<li><p>Ignore per-base sequence content. This in RNA-seq is known to be a bit messed up since the typical cDNA primer binding introduces some bias at the 5' end. I cannot really explain what the direct implication of GC content is, but can say with confidence that I really never really cared about this warning (or error) and never got into any trouble with it. Sequence length distribution gets warning if sequences are of different length, which is normal after trimming.</p>
</li>
</ol>
<p>&quot;Per base sequence content&quot; is fine as well, it's only the first base that is a bit odd (not sure why) but I would not worry. Aligners will soft-clip it off if it causes mismatch alignments.</p>
<p>The question you need to ask is whether trimming is even necessary. My personal take on RNA-seq is that trimming only makes sense if you have adapter contamination. If not, skip it.</p>

CC BY-SA 4.0
2024-06-12T14:28:12.870Z
Hello @ATpoint, Thank you for your reply! You're correct it appears that all adapters are already trimmed off. However, I still received many of the same errors. I attached the plots that threw errors/warnings in my question above. Thank you for your help!
tphinney
CC BY-SA 4.0
2024-06-13T07:04:53.193Z
It is unlikely that you get raw data that are trimmed. But in regular RNA-seq you simply have no adapter content as inserts are typically longer than reads, so no adapters you pick up.
ATpoint
CC BY-SA 4.0
2024-06-11T21:18:15.967Z
2024-06-13T07:04:47.763Z
2024-06-13T07:04:47.763Z
ATpoint
<p>Looking at the plots, the only one I'd look into further is the per-sequence GC content, because the distribution is quite skewed in comparison to the theoretical distribution. This could be explained away if you're using a patterned flow cell with single-dye chemistry (e.g. NovaSeq), because their &quot;no signal&quot; sequence is a string of Gs (which would show up as a spike on a graph). Another explanation would be contamination with bacterial or other non-sample RNA; in many cases such contamination can be checked for by looking for ribosomal RNA in the reads.</p>
<p>Given that you're looking at cDNA reads, the per-base sequence content looks fine. cDNA reads often have an abundance of As and Ts near the ends thanks to the polyA tail, and the other slight over-representation near the end is G, which (as mentioned) might already be expected in Illumina reads.</p>
<p>As others have discussed, the overrepresented sequences are a low enough fraction that it's probably not going to be an issue with analysis.</p>
<p>I see that you've also included &quot;Sequence Duplication Levels&quot;, that includes a statement &quot;Percent of seqs remaining if deduplicated 40.79%&quot;. That level of duplication strikes me as odd, possibly pointing to something like a B-cell spitting out millions of copies of its receptor transcript - I use this as a demonstrative example because I've encountered it myself, not because I think that's happening with your data. Such a situation could also explain the GC content difference as well, because there will be less transcript diversity.</p>

CC BY-SA 4.0
2024-06-12T22:05:00.557Z
2024-06-12T22:05:00.557Z
gringer
<p>I am new to coding and especially new to bioinformatics so I am sorry if this is a dumb question. Nevertheless, I am attempting to run Trim Galore! to trim my paired RNAseq data, there are no error messages that get thrown when trim is running. However, when I check the fastQC reports there are a ton of indicators showing the data is low quality. I am unsure of what I am missing and would really appreciate some help. The only thing I find odd is there are low adapter counts and I am not really sure why this is.</p>
<p>Found perfect matches for the following adapter sequences:</p>
<div class="s-table-container"><table class="s-table">
<thead>
<tr>
<th>Adapter type</th>
<th>Count</th>
<th>Sequence</th>
<th>Sequences analysed</th>
<th>Percentage</th>
</tr>
</thead>
<tbody>
<tr>
<td>Nextera</td>
<td>11</td>
<td>CTGTCTCTTATA</td>
<td>1000000</td>
<td>0.00</td>
</tr>
<tr>
<td>smallRNA</td>
<td>10</td>
<td>TGGAATTCTCGG</td>
<td>1000000</td>
<td>0.00</td>
</tr>
<tr>
<td>Illumina</td>
<td>0</td>
<td>AGATCGGAAGAGC</td>
<td>1000000</td>
<td>0.00</td>
</tr>
</tbody>
</table></div>
<p>Using Nextera adapter for trimming (count: 11). Second best hit was smallRNA (count: 10)</p>
<p>This is the code I am running to run Trim Galore:</p>
<pre><code>trim_galore --paired --fastqc --length 20 --adapter  -o /path/to/R1_file /path/to/R2_file
</code></pre>
<p>My FastQC reports fail at the following parameters:</p>
<ul>
<li>Per base sequence quality</li>
<li>Per base sequence content</li>
<li>Per sequence GC content</li>
<li>Sequence Length Distribution</li>
</ul>
<p>I also have a warning error at &quot;Over represented sequences&quot; with 17 sequences all with no possible sources. As I mentioned above any help or advice would be greatly appreciated.</p>
<p>UPDATE
I ran FASTQC on my untrimmed fastq data and received the same errors/warnings. I have attached the plots below.  <a href="https://i.sstatic.net/nSJDeiDP.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/nSJDeiDP.png" alt="enter image description here" /></a></p>
<p><a href="https://i.sstatic.net/O6fQSV18.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/O6fQSV18.png" alt="enter image description here" /></a></p>
<p>[<img src="https://i.sstatic.net/pQW3LUfg.png" alt="enter image description here" /><a href="https://i.sstatic.net/pQW3LUfg.png" rel="nofollow noreferrer">3</a></p>
<p><a href="https://i.sstatic.net/Jf06cw2C.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Jf06cw2C.png" alt="enter image description here" /></a></p>
<p><a href="https://i.sstatic.net/YZVN7Dx7.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/YZVN7Dx7.png" alt="enter image description here" /></a></p>
<p><a href="https://i.sstatic.net/iVFc5oKj.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/iVFc5oKj.png" alt="enter image description here" /></a></p>

CC BY-SA 4.0
2024-06-11T17:46:08.600Z
Why would you expect to find 3 different adapters? Which one did you actually use? And as far as I know, sequencers (at least most Illumina DNA machines) have a setting to remove adapters, are you sure you have any there? Your table shows you basically do not have any adapters, what you see are just random matches (note the 0%).
terdon
CC BY-SA 4.0
2024-06-11T18:07:01.563Z
@terdon, this was my initial thought. I just had no other explanation for why the reads were failing the fastQC. Is there something else I should be doing to ensure the quality of the reads?
tphinney
CC BY-SA 4.0
2024-06-11T18:11:09.797Z
It would help if you could post the fastq output, for one thing, so we can see exactly what is going on. That said, fastq is quite strict. I work for a company that analyzes thousands of sequencing samples a year and my intuition without actually doing the counting is that most of them fail some FastQC test or other. Is there nobody more experienced around who can help? This is more of a biology/biochemistry thing than a bioinformatics one, really.
terdon
<ngs><trimming>
Issues with adapter trimming (Trim Galore)
# Issues with adapter trimming (Trim Galore)

(Asked by: username_0 on 2024-06-11)

I am new to coding and especially new to bioinformatics so I am sorry if this is a dumb question. Nevertheless, I am attempting to run Trim Galore! to trim my paired RNAseq data, there are no error messages that get thrown when trim is running. However, when I check the fastQC reports there are a ton of indicators showing the data is low quality. I am unsure of what I am missing and would really appreciate some help. The only thing I find odd is there are low adapter counts and I am not really sure why this is.
Found perfect matches for the following adapter sequences:



Adapter type
Count
Sequence
Sequences analysed
Percentage




Nextera
11
CTGTCTCTTATA
1000000
0.00


smallRNA
10
TGGAATTCTCGG
1000000
0.00


Illumina
0
AGATCGGAAGAGC
1000000
0.00



Using Nextera adapter for trimming (count: 11). Second best hit was smallRNA (count: 10)
This is the code I am running to run Trim Galore:
trim_galore --paired --fastqc --length 20 --adapter  -o /path/to/R1_file /path/to/R2_file

My FastQC reports fail at the following parameters:

Per base sequence quality
Per base sequence content
Per sequence GC content
Sequence Length Distribution

I also have a warning error at "Over represented sequences" with 17 sequences all with no possible sources. As I mentioned above any help or advice would be greatly appreciated.
UPDATE
I ran FASTQC on my untrimmed fastq data and received the same errors/warnings. I have attached the plots below.  

[3

**Tags:** ngs, trimming
> **Comments:**
> **username_1**: Why would you expect to find 3 different adapters? Which one did you actually use? And as far as I know, sequencers (at least most Illumina DNA machines) have a setting to remove adapters, are you sure you have any there? Your table shows you basically do not have any adapters, what you see are just random matches (note the 0%).  
> **username_0**: @terdon, this was my initial thought. I just had no other explanation for why the reads were failing the fastQC. Is there something else I should be doing to ensure the quality of the reads?  
> **username_1**: It would help if you could post the fastq output, for one thing, so we can see exactly what is going on. That said, fastq is quite strict. I work for a company that analyzes thousands of sequencing samples a year and my intuition without actually doing the counting is that most of them fail some FastQC test or other. Is there nobody more experienced around who can help? This is more of a biology/biochemistry thing than a bioinformatics one, really.  

---

## 2 answers

### Answer by username_2 on 2024-06-11. Score: 2

1. Ignore the overrepresented sequences. The counts for these that you show is so low (10, 11) that it is irrelevant.
2. Ignore per-base sequence content. This in RNA-seq is known to be a bit messed up since the typical cDNA primer binding introduces some bias at the 5' end. I cannot really explain what the direct implication of GC content is, but can say with confidence that I really never really cared about this warning (or error) and never got into any trouble with it. Sequence length distribution gets warning if sequences are of different length, which is normal after trimming.

"Per base sequence content" is fine as well, it's only the first base that is a bit odd (not sure why) but I would not worry. Aligners will soft-clip it off if it causes mismatch alignments.

The question you need to ask is whether trimming is even necessary. My personal take on RNA-seq is that trimming only makes sense if you have adapter contamination. If not, skip it.

> **Comments:**
> **username_0**: Hello @ATpoint, Thank you for your reply! You're correct it appears that all adapters are already trimmed off. However, I still received many of the same errors. I attached the plots that threw errors/warnings in my question above. Thank you for your help!  
> **username_2**: It is unlikely that you get raw data that are trimmed. But in regular RNA-seq you simply have no adapter content as inserts are typically longer than reads, so no adapters you pick up.  

---

### Answer by username_3 on 2024-06-12. Score: 1

Looking at the plots, the only one I'd look into further is the per-sequence GC content, because the distribution is quite skewed in comparison to the theoretical distribution. This could be explained away if you're using a patterned flow cell with single-dye chemistry (e.g. NovaSeq), because their "no signal" sequence is a string of Gs (which would show up as a spike on a graph). Another explanation would be contamination with bacterial or other non-sample RNA; in many cases such contamination can be checked for by looking for ribosomal RNA in the reads.

Given that you're looking at cDNA reads, the per-base sequence content looks fine. cDNA reads often have an abundance of As and Ts near the ends thanks to the polyA tail, and the other slight over-representation near the end is G, which (as mentioned) might already be expected in Illumina reads.

As others have discussed, the overrepresented sequences are a low enough fraction that it's probably not going to be an issue with analysis.

I see that you've also included "Sequence Duplication Levels", that includes a statement "Percent of seqs remaining if deduplicated 40.79%". That level of duplication strikes me as odd, possibly pointing to something like a B-cell spitting out millions of copies of its receptor transcript - I use this as a demonstrative example because I've encountered it myself, not because I think that's happening with your data. Such a situation could also explain the GC content difference as well, because there will be less transcript diversity.


---

