# lower mapping rates in salmon v0.13 compared to previous versions

Hi there :) Thanks for the tool!

I recently updated to the new salmon (from 0.8... its been a couple years) and I noticed that my mapping percentages change dramatically between the two versions.

For example, using the default settings in v0.8, I see a mapping rate of 96.25% however upon upgrading to v0.13, these mapping rates go down to 82-84% depending on which of the parameters I play with (I've permutated the validateMappings, incompatPrior, consensusSlack, minScoreFraction, ma, etc). Below I have a snippet of one of these tests. I'm currently assembling the unmapped reads to see if I can determine why these reads were not mapped.

What do you think is the most likely cause for this dramatic change in performance?

Perhaps it could be the transcript index? (I used a kmer of 31 and my reads are 100 bp).

UPDATE:

I have run the indexing and quasi-mapping using salmon v0.8, v0.10 (when validateMappings was released), v0.12, v0.13 and had mapping rates of 96, 90, 90 and 83 respectively. So it looks like a gradual decay of mapping rates. Or alternatively, a gradual reduction in spurious mapping?

Seems like what ever improvements from 0.12 to 0.13 changed the mapping rates significantly. I will go ahead with both mappings (v0.12 and v0.13) to see if there are differences in the DESEQ2 outputs.

Thanks a lot! (while I have presented values here for one set of fastq files, the same pattern is seen throughout all 72 of my samples from different experiments)

for F in $$FILES ; do R1=$${F}_L001_R1_001.fastq.gz
R2=$${F}_L001_R2_001.fastq.gz salmon quant \ -p 35 \ -i$$ref_dir/$$transcript_index \ -l A \ -1$$R1 \
-2 $$R2 \ -o$$(basename \$F).VM.rFB4.IP9.quant \
--incompatPrior 9.9999999999999995e-21 \  # default of v0.8
--writeUnmappedNames \
--validateMappings \
--rangeFactorizationBins 4

done


Update salmon is now released with a --allowDovetail option in 0.13.1 and inspected via a -z dump.

• Hi Courtney, Thanks so much for the detailed report! Would you be able to share one of your samples (and the target transcriptome)? We'd be happy to explore this is more detail to determine exactly whats going on, and if its "correct" or not. Thanks, Rob Mar 6 '19 at 13:50
• Thanks, Courtney, for sharing the data and for the detailed description! We'll look into it ASAP and get back to you with what we find. Also, please let me know if there's a better way to contact you than the comments of this post :). Mar 7 '19 at 15:46
• Hi Courtney, We've looked into the data and identified the source of the different mapping rates. Specifically, the cause is discordant reads; in this case reads that are dovetailing with respect to their positions on the reference. If you run Bowtie2 with "RNA-seq" flags (i.e. disallowing discordant mappings), then you get essentially the same mapping rate as salmon here. Is allowing dovetailing reads something that should be very important in your analysis? If so, we can consider what would be necessary to add back support, but generally, they provide evidence of tenuous quality. Mar 7 '19 at 20:19
• Thanks for your help!! If I understand correctly, dovetailing is when a read extends beyond the boundary of its mate? I wonder how this could happen? (i) Small library insert size? (ii) Repeats? This organism has a lot of multi-copy genes that are nearly identical (in fact, this transcriptome has already been reduced at 98% nt id). However, there are still hundreds of genes that are low-complexity and similar. Maybe these mates are not dovetailing per se, but rather hitting similar repeats in these genes? Mar 8 '19 at 9:25