Blog:Salmon Kallisto HtSeq-count for gene level analysis - Anecdotal evidence

Question

[Ido Tamir]

With the new tools I was again unsure on how to proceed and I could not give my customers 3 different results and tell them to choose the one they like best. So I did an unscientific study based on one dataset to devise a strategy and judge the differences.

I would be glad if other people do similar things more systematically, especially add the two methods to Seqc (this one or this one) or simply post their opinion or experiences.

Blog

[Rob]

Hi Ido,

I was wondering if you could mention the versions of these software you used. In particular, there have been substantial improvements in Salmon v0.4.0, and I wonder if this analysis was performed with an older version (and how difficult it would be to replicate with the new version).

Thanks,
Rob

[Ido Tamir]

Not good at all. Now the results are very similar ;-).

[Ido Tamir]

Good point, I added some version info.

Salmon (0.3.0) I have from the binary you provided. I have this old system where I cant compile anything new, so I would need a binary.

[Rob]

Thanks for the update! Actually, v0.3.0 is a few releases behind. The development of salmon has moved to it's own repository (sorry; I should announce this on the user-list!). The binaries for v0.4.0 are available here. In particular, the "DebianSqueeze" binary is built on a VM of a fairly old version of Debian so, hopefully, it will work on your machine. I'd be interested to see how this changes the analysis!

[Ido Tamir]

Thanks

I think there is some debug output enabled in the squeeze version. I get megabytes of:

expected = Library format { type:single end, relative orientation:none, strandedness:antisense }
observed = Library format { type:single end, relative orientation:none, strandedness:sense }
expected = Library format { type:single end, relative orientation:none, strandedness:antisense }
..
..

[Rob]

Hrmm --- I can certainly take care of this, but what is the library type? It looks like you're providing -l SR (single-end, with the read coming from the antisense strand) and it's expecting either -l U (single-end, unstranded) or -l SF (single-end, with the read coming from the sense strand).

[Ido Tamir]

The data is single end coming from the antisense strand. i.e. standard UTP protocol as indicated in the plots in the blog post. I provide -I SR. The mapping rate looks OK. One problem is that now I get a core dump for the genes (same input as 0.3.0). I posted in the sailfish-google group.

# salmon (smem-based) v0.4.0
# [ program ] => salmon
# [ command ] => quant
# [ threads ] => { 4 }
# [ libType ] => { SR }
# [ unmatedReads ] => { /groups/csf-ngs/projects/20140428_jurkin_diffexp/data/fasta/henkel/C6A1GANXX_1#23728_TGACCA.1.fastq }
# [ index ] => { /groups/csf-ngs/projects/20140428_jurkin_diffexp/data/salmon/human/Homo_sapiens.GRCh38 }
# [ extraSensitive ] => { }
# [ biasCorrect ] => { }
# [ geneMap ] => { /groups/csf-ngs/projects/20140428_jurkin_diffexp/data/salmon/human/Homo_sapiens.GRCh38.79.chr.gtf }
# [ output ] => { /groups/csf-ngs/projects/20140428_jurkin_diffexp/results/salmon/henkel/C6A1GANXX_1#23728_TGACCA }
# [ mapping rate ] => { 86.8205% }
# Name    Length    TPM    NumReads

[Rob]

Hi Ido,

Thanks for reporting this. I've disabled the "annoying" reporting of the unexpected fragment orientation, and fixed (I believe) the bug you ran into with the post-hoc bias correction. I've updated the binary on GitHub and responded to your post on the sailfish-google group (thanks for posting there). Let me know if the new release resolves this issue, and I'll roll those changes into a v0.4.1 bump.