salmon 1.1.0 release notes

salmon 1.1.0 release notes

Note : This version contains some important fixes, please see below for detailed information.

Note : On our testing machines, this version of salmon was index-compatible with version 1.0.0. That is, it is likely that you need not re-build your index from what you built with 1.0.0. However, it is not clear that this compatibility is guaranteed by the cereal library. If you encounter difficulty loading a previously-built index, please consider re-building with the latest version before filing a bug report.

Note : If you want to build from source and use a version of the (header-only) cereal library already installed on your system, please make sure it is cereal v1.3.0. The current findCereal.cmake file does not support version restrictions, and we are working to improve this for proper automatic detection and enforcement of this constraint in future releases.

As always, a pre-compiled linux executable is included below and the latest release is available via Bioconda.

Improvements

• SHA512 sums are now properly propagated forward to meta_info.json.

• Bumped the included version of the cereal serialization library. The components used by salmon should be backward compatible in terms of reading output from the previous version (i.e. should not require index re-building).

• The flag --keepFixedFasta was added to the index command. If this flag is passed, then a "fixed" version of the fasta file will be retained in the index directory. This file is created during indexing, but is normally deleted when indexing is complete. It contains the input fasta without duplicate sequences (unless --keepDuplicates was used), with the headers as understood by salmon, with N nucleotides replaced, etc.

• Introduced a few small optimizations upstream (in pufferfish) to speed up selective-alignment; more are on the way (thanks to @mohsenzakeri).

Bug fixes

• The bug described directly below led to the discovery of a different but related bug that could cause the extracted sequence used for bias correction to be incorrect. The code was assuming zero-initalization of memory which was not necessarily occuring. Note: This bug affects runs performed under mapping-based mode (i.e. when the input was not coming from a BAM file) and when --seqBias or --gcBias flags (or both) were used. Depending upon the initialization of the underlying memory, the bug may lead to unexpected results and diminished accuracy. The bug was present in versions 0.99.0 beta 1 through 1.0.0 (inclusive), and if you processed data using these versions in mapping-based mode with the flags mentioned above, we encourage you to reprocess this data with the newest version, just in case. We apologize for any inconvenience.

• Fixed a bug that would occur when the input fasta file contained short sequences (<= length k) near the end of the file and bias correction (sequence-specific or fragment-GC) was enabled. This is particularly acute when the short sequence was immediately preceded by a very long target and would cause inordinate warning message printing to the log (hugely slowing down index loading). This printing to the log could slow the index loading considerably. Furthermore, this would provide sequence copies to short transcripts and decoy sequences even though they are not needed, which would result in unnecessary memory waste. The bug was due to a missing parenthesization to enforce the desired operator precedence. This fix should speed up index loading and reduce memory usage when using the --seqBias or --gcBias flags. Huge thanks to @mdshw5 for finding an input that would trigger this behavior (which didn't show up in testing), and for helping to track down the cause.

• Fixed a bug that could occur in computing the Beta function component of the chaining score with very long queries. This should not have shown up at all with Illumina-length reads, but nonetheless the adjustment conceptually corrects the scoring for all cases. Thanks @mohsenzakeri.