Hi. Our team was using the pipeline for OSCC transcriptome analysis, and we found something strange. We initially set the strandedness detection to AUTO, and had ~70% to 90% reads mapped for 60% of the samples (the rest of the samples had too low mapping rates, even below 20%). But specifying the strandedness (as per the lib prep protocol) in the sample csv improved mapping rates to >95% for almost all samples! Is this an expected behavior when AUTO mode detected strandedness correctly (reverse for all the samples)?

The mapping rate has nothing to do with the strandedness, so I'm not sure we are on the same page here regarding nomenclature. STAR maps the reads to the genome wherever they fit, it does not concern itself with the strand, except that it tries both. The strandedness is important when it comes to counting, and that is by default done by Salmon (which also does the determination used by

auto

). If a gene is on the

+

-strand and your library is

reverse

stranded, then (almost) all of the reads are expected to be on the

-

-strand, and if the strandedness is set to

reverse

, then only those reads would count towards the gene (or its transcripts). (Analogous for

forward

, for

unstranded

reads from both strands count.) Because in most libraries ~2% (more in bad ones) of reads are on the "wrong" strand, counting with

unstranded

should almost always yield the most reads. The exception is when there are two genes that have overlapping coordinates, but are on different strands (e.g. a gene and a regulatory microRNA). In that case the

unstranded

method does not know to which gene a read belongs (Salmon will split the counts, STAR or featureCounts will not count them at all), but a stranded counting method will be unambiguous and therefore have higher counts. The way

auto

works is that it counts separately for both

forward

and

reverse

, and if one of them has high counts and the other very low, then the strandedness is clear. If they are comparable (~50:50), then the protocol is

unstranded

. But if the situation does not fit either of these scenarios, you should get a warning, because something weird is going on (e.g. DNA contamination on top of a stranded protocol). In that case not relying on

auto

may be safer and more accurate, although if you really have something going on that screws up strandedness to this extent, them you probably should not be using these samples at all. With

auto

, there are actually two counting steps -- the first one (on a a subsample) is used to determine the strandedness (as described above), but once that is done, it will use that to do the full count in the same way as if you had specified it yourself, i.e. the only time manually specifying the strandedness will have different results from

auto

is when

auto

comes to the wrong conclusion, which only happens if your samples are bad. (Note that running Salmon twice with the exact same parameters will still give slightly different counts every time, because it uses some random component. But that's a small difference and not what I am talking about.) Do you mean counting rates? (The mapping rate is (total reads - unmapped reads)/total reads, whereas the counting rate is counted reads/mapped reads.) If so,

auto

should ideally give the correct results (same as manually specified, provided you do that correctly), unless your samples have serious issues.

I agree, and even i thought the same. But somehow using the same params except for strandedness gave higher mapping rates, so wanted to confirm if there is an issue here. Thanks

As I said, the mapping should have been complete before any tool even looks at the strandedness. If you have two runs, compare the BAM files -- except for any stochastic differences, they should effectively be the same. You can run some version of

samtools view -c

on the BAMs (e.g. with

-F 276

, see here for options, it will only count mapped R1 reads, and only once, even if they multimap) to do your own calculation of the mapped reads and the mapping rate. There is likely a bug, probably in the tool that reports the "mapping rate" ...

Sure. Thanks