<p>A likely explanation is that total RNA-Seq contains a high fraction of reads from ribosomal RNAs. Ribosomal RNAs are present in multiple copies across the genome, hence many reads map to multiple genomic locations and get discarded by the aligner. For example, STAR with default parameters considers a read as unmapped if it maps to more than 10 genomic loci (this behavior can be changed with the <code>--outFilterMultimapNmax</code> option).
To confirm if this is actually the case, you could check the number of multi-mapping reads in the aligner's log files. </p>

CC BY-SA 3.0
2017-11-22T13:11:57.487Z
I tried to increase the number of allowed multimapping reads and indeed the number of reads mapped to multiple loci has increased, albeit slightly (6.92% to 7.50%). Most of the non-mapped are categorised into "too short" (in STAR). Do you have any ideas what are these (well, it refers back to my initial question, since this happen in Salmon as well)?
kaka01
CC BY-SA 3.0
2017-11-22T13:36:11.863Z
Are you trimming adapters from the reads prior to mapping? That might explain the many "too short" reads. Also, have a look at this issue on STAR's Github repo: https://github.com/alexdobin/STAR/issues/169
Tom
CC BY-SA 3.0
2017-11-22T16:33:07.867Z
@kaka01 If accounting for multi-mapping doesn’t solve your problem then there may simply be something wrong with your data: on high quality data sets, mapping total RNA to a genomic reference should typically yield >80% mapped reads. Many “too short” mappings may be indicative of RNA fragments. Did you perform size selection before sequencing?
Konrad Rudolph
CC BY-SA 3.0
2017-11-23T09:44:40.283Z
Tom: No trimming was done prior to mapping. @Konrad The libraries weren't size selected. Your explanation makes sense, aligning the unmapped reads to the collection of rRNAs yielded high mapping rate (which is a sign that those are really rRNAs). Still not sure why STAR classified them as too short, maybe I just have to play around more with the parameters.
kaka01
CC BY-SA 3.0
2017-11-23T10:06:23.090Z
@kaka01 “Too short” here simply means that STAR is unable to align the read with high quality: either because the initial read (after trimming) is so short that it could match the reference virtually anywhere (< ~14 bases for something like the human genome) so we have low confidence in the correct origin. Or because STAR, when running with `--alignEndsType Local` (which is the default) is only able to match a small part of the read (which then leads back to the first problem).
Konrad Rudolph
CC BY-SA 3.0
2017-11-23T11:47:48.380Z
@kaka01 Since you didn't do size selection, it's possible that you have a high number of short fragments, and you end up sequencing the adapter. You could try to trim the adapter and map the reads again. This might help to mitigate the issue because in STAR the minimum mapped length if a fraction of the total read length.
Tom
CC BY-SA 3.0
2017-11-23T11:50:45.933Z
@KonradRudolph in you answer you say that _mixed library of short and long RNA doesn’t seem to cycle well through the whole fragment length_. I wasn't aware of this issue, do you know why this is the case? (sorry for commenting here, I don't have enough reputation to comment you answer directly)
Tom
CC BY-SA 3.0
2017-11-23T12:25:05.807Z
@Tom Let’s talk offline (are you at the RNA club tonight? I’ll attend.) In short, I have no confirmation but it’s what we observe, and I don’t find it implausible given the chemistry.
Konrad Rudolph
CC BY-SA 3.0
2017-11-21T13:40:50.957Z
2017-11-21T13:40:50.957Z
Tom
<p>In particular for mouse, this can happen if the ribo-depletion wasn't terribly efficient, since there's no <a href="https://www.ncbi.nlm.nih.gov/gene/100861531" rel="nofollow noreferrer">Rn45s sequence</a> in the reference genome. That, combined with numerous copies of tRNAs, 5S rRNAs, etc. causing issues with multimappers (see the answer from @Tom) can heavily decrease alignment rates.</p>

<p>Note that the human reference genome contains a few copies of the 45S (e.g., on GL000220.1 and chr21), so these reads will all multimap (possibly too many times). I don't know about the zebrafish reference genome.</p>

CC BY-SA 3.0
2017-11-21T14:05:11.907Z
2017-11-21T14:05:11.907Z
Devon Ryan
<p>When sequencing RNA from freshly harvested tissues under proper conditions, you should generally expect > 50% mapped reads. In fact, everything &lt; 80% would usually raise concerns.</p>

<p>From your description (in the question and comments) it sounds as if your samples are potentially degraded and therefore saturated with short RNA fragments, either because you’ve got old tissue, you’re looking at environmental samples, or from improper handling.</p>

<p>And since you’re not performing any enrichment, the sequencing data will then be highly saturated with degraded RNA, too. The reason for this is that RNA-seq is a (hopefully somewhat uniform) sampling of your sample aliquot: everything in it is proportionally represented in the RNA-seq data. That’s why enrichment steps are important, to increase the proportion of whatever fraction we’re interested in.</p>

<p>In particular,</p>

<ol>
<li>Total RNA is mostly composed of genes with many copies: mostly rRNA and (much less) tRNA. Hence the importance of ribosome depletion or poly(A) selection.</li>
<li>RNA in general is unstable. Depending on the sample collection (non-tissue sample origin? age of the tissue before harvesting?), a large fraction of the RNA may have degraded into minuscule fragments, which are further shortened by the library preparation. Size selection would get rid of these undesired fragments.</li>
</ol>

<p>In my experience, the second issue is exacerbated on certain sequencers (I’ve seen it on an Illumina HiSeq 1500) because a mixed library of short and long RNA doesn’t seem to cycle well through the whole fragment length. So even if you have a (small but still present) fraction of long RNA fragments, the sequencer may not be able to synthesise their whole length efficiently. The effect is that there are proportionally more short reads than there were short fragments in the sample.</p>

<p>You can verify this by calculating the insert size distribution of your reads after adapter trimming (e.g. using picard, or by simply tallying read lengths<sup>1</sup>). Small reads (&lt; ~14 nt) from degradation fragments are essentially unmappable, since they are too short to have a specific identity. Even if we allowed the mapper to align them their coordinates would be essentially random.</p>

<hr>

<p><sup>1</sup> This works:</p>

<pre><code>awk 'NR % 4 == 2 {c[length($0)]++} END {for (i in c) print i, c[i]}' in.fastq
</code></pre>

CC BY-SA 3.0
2017-11-23T10:52:12.513Z
2017-11-23T10:52:12.513Z
Konrad Rudolph
<p>You can't assume that the rRNA genes are in the genome. There many copies of them and not all are placed on chromosomes. We've had this issue with human and mouse data for total RNA preps. You need to ensure you map against the <em>whole</em> genome not just the chromosomes.</p>

CC BY-SA 3.0
2017-11-22T13:25:28.280Z
I 'm mapping to the whole genome indeed. But anyways, assuming that you are mapping against the whole genome, did you get significantly higher mapping rate?
kaka01
CC BY-SA 3.0
2017-11-22T11:46:40.057Z
2017-11-22T11:46:40.057Z
ithinkiam
<p>Maybe this is a silly question, but I'm really wondering why we usually get low mapping rates if we map total RNA-seq, but not poly(A)-enriched (in particular, for human, mouse, and zebrafish datasets)? </p>

<p>Doesn't the genome fasta file contain ribosomal RNAs (which are abundantly expected in the total RNA-seq libraries) as well?</p>

<p>I don't have the numbers for human right now, but I recall previously having low mapping rates for human data as well. What triggered me at the moment is actually when I mapped zebrafish data. I got around 60% mapping to the genome and 45% to the transcriptome with one dataset and 36% - 35% with another dataset (note that these are from 2 different studies and both are total RNA-seq, mapping was done using STAR and Salmon, which have their own methods).</p>

CC BY-SA 3.0
2017-11-21T11:04:17.923Z
It can also happen if you map to a transcriptome sequence instead of the genome sequence because there can be a lot of intron sequence from unprocessed mRNA and from unannotated non-coding RNAs
heathobrien
<rna-seq><read-mapping><mappability>
Why total RNA-seq usually yields low mapping rate?
# Why total RNA-seq usually yields low mapping rate?

(Asked by: username_0 on 2017-11-21)

Maybe this is a silly question, but I'm really wondering why we usually get low mapping rates if we map total RNA-seq, but not poly(A)-enriched (in particular, for human, mouse, and zebrafish datasets)?

Doesn't the genome fasta file contain ribosomal RNAs (which are abundantly expected in the total RNA-seq libraries) as well?

I don't have the numbers for human right now, but I recall previously having low mapping rates for human data as well. What triggered me at the moment is actually when I mapped zebrafish data. I got around 60% mapping to the genome and 45% to the transcriptome with one dataset and 36% - 35% with another dataset (note that these are from 2 different studies and both are total RNA-seq, mapping was done using STAR and Salmon, which have their own methods).

**Tags:** rna-seq, read-mapping, mappability
> **Comments:**
> **username_1**: It can also happen if you map to a transcriptome sequence instead of the genome sequence because there can be a lot of intron sequence from unprocessed mRNA and from unannotated non-coding RNAs  

---

## 4 answers

### Answer by username_2 on 2017-11-21. Score: 5

A likely explanation is that total RNA-Seq contains a high fraction of reads from ribosomal RNAs. Ribosomal RNAs are present in multiple copies across the genome, hence many reads map to multiple genomic locations and get discarded by the aligner. For example, STAR with default parameters considers a read as unmapped if it maps to more than 10 genomic loci (this behavior can be changed with the `--outFilterMultimapNmax` option).
To confirm if this is actually the case, you could check the number of multi-mapping reads in the aligner's log files.

> **Comments:**
> **username_0**: I tried to increase the number of allowed multimapping reads and indeed the number of reads mapped to multiple loci has increased, albeit slightly (6.92% to 7.50%). Most of the non-mapped are categorised into "too short" (in STAR). Do you have any ideas what are these (well, it refers back to my initial question, since this happen in Salmon as well)?  
> **username_2**: Are you trimming adapters from the reads prior to mapping? That might explain the many "too short" reads. Also, have a look at this issue on STAR's Github repo: https://github.com/alexdobin/STAR/issues/169  
> **username_3**: @kaka01 If accounting for multi-mapping doesn’t solve your problem then there may simply be something wrong with your data: on high quality data sets, mapping total RNA to a genomic reference should typically yield >80% mapped reads. Many “too short” mappings may be indicative of RNA fragments. Did you perform size selection before sequencing?  
> **username_0**: Tom: No trimming was done prior to mapping. @Konrad The libraries weren't size selected. Your explanation makes sense, aligning the unmapped reads to the collection of rRNAs yielded high mapping rate (which is a sign that those are really rRNAs). Still not sure why STAR classified them as too short, maybe I just have to play around more with the parameters.  
> **username_3**: @kaka01 “Too short” here simply means that STAR is unable to align the read with high quality: either because the initial read (after trimming) is so short that it could match the reference virtually anywhere (< ~14 bases for something like the human genome) so we have low confidence in the correct origin. Or because STAR, when running with `--alignEndsType Local` (which is the default) is only able to match a small part of the read (which then leads back to the first problem).  
> **username_2**: @kaka01 Since you didn't do size selection, it's possible that you have a high number of short fragments, and you end up sequencing the adapter. You could try to trim the adapter and map the reads again. This might help to mitigate the issue because in STAR the minimum mapped length if a fraction of the total read length.  
> **username_2**: @KonradRudolph in you answer you say that _mixed library of short and long RNA doesn’t seem to cycle well through the whole fragment length_. I wasn't aware of this issue, do you know why this is the case? (sorry for commenting here, I don't have enough reputation to comment you answer directly)  
> **username_3**: @Tom Let’s talk offline (are you at the RNA club tonight? I’ll attend.) In short, I have no confirmation but it’s what we observe, and I don’t find it implausible given the chemistry.  

---

### Answer by username_4 on 2017-11-21. Score: 3

In particular for mouse, this can happen if the ribo-depletion wasn't terribly efficient, since there's no [Rn45s sequence](https://www.ncbi.nlm.nih.gov/gene/100861531) in the reference genome. That, combined with numerous copies of tRNAs, 5S rRNAs, etc. causing issues with multimappers (see the answer from @Tom) can heavily decrease alignment rates.

Note that the human reference genome contains a few copies of the 45S (e.g., on GL000220.1 and chr21), so these reads will all multimap (possibly too many times). I don't know about the zebrafish reference genome.


---

### Answer by username_3 on 2017-11-23. Score: 2

When sequencing RNA from freshly harvested tissues under proper conditions, you should generally expect > 50% mapped reads. In fact, everything < 80% would usually raise concerns.
From your description (in the question and comments) it sounds as if your samples are potentially degraded and therefore saturated with short RNA fragments, either because you’ve got old tissue, you’re looking at environmental samples, or from improper handling.
And since you’re not performing any enrichment, the sequencing data will then be highly saturated with degraded RNA, too. The reason for this is that RNA-seq is a (hopefully somewhat uniform) sampling of your sample aliquot: everything in it is proportionally represented in the RNA-seq data. That’s why enrichment steps are important, to increase the proportion of whatever fraction we’re interested in.
In particular,

Total RNA is mostly composed of genes with many copies: mostly rRNA and (much less) tRNA. Hence the importance of ribosome depletion or poly(A) selection.
RNA in general is unstable. Depending on the sample collection (non-tissue sample origin? age of the tissue before harvesting?), a large fraction of the RNA may have degraded into minuscule fragments, which are further shortened by the library preparation. Size selection would get rid of these undesired fragments.

In my experience, the second issue is exacerbated on certain sequencers (I’ve seen it on an Illumina HiSeq 1500) because a mixed library of short and long RNA doesn’t seem to cycle well through the whole fragment length. So even if you have a (small but still present) fraction of long RNA fragments, the sequencer may not be able to synthesise their whole length efficiently. The effect is that there are proportionally more short reads than there were short fragments in the sample.
You can verify this by calculating the insert size distribution of your reads after adapter trimming (e.g. using picard, or by simply tallying read lengths1). Small reads (< ~14 nt) from degradation fragments are essentially unmappable, since they are too short to have a specific identity. Even if we allowed the mapper to align them their coordinates would be essentially random.

1 This works:
awk 'NR % 4 == 2 {c[length($0)]++} END {for (i in c) print i, c[i]}' in.fastq


---

### Answer by username_5 on 2017-11-22. Score: 1

You can't assume that the rRNA genes are in the genome. There many copies of them and not all are placed on chromosomes. We've had this issue with human and mouse data for total RNA preps. You need to ensure you map against the *whole* genome not just the chromosomes.

> **Comments:**
> **username_0**: I 'm mapping to the whole genome indeed. But anyways, assuming that you are mapping against the whole genome, did you get significantly higher mapping rate?  

---

