Salmon v0.7.1

Salmon 0.7.1

Salmon 0.7.1 is a bug-fix release. In maintains all of the major changes and improvements implemented in v0.7.0, but improves program behavior and fixes a few bugs (most of which predate v0.7.0). It is recommended that all users upgrade to v0.7.1 when possible.

New minor feature:

• The --gencode flag has been added as an optional flag to the index building step. When building the quasi index, this will expect the transcript fasta to be in Gencode format. Instead of using the entire line following > as the transcript name, it will split the header at the first occurrence of the | character, and will use the first token preceding this | as the transcript name. This will make the names used from the fasta file properly correspond to the name the transcripts are given in the GTF. Thanks to @nicolasstransky for suggesting this feature.

Improved program behavior:

• Salmon invoked with no options returns exit code 1 (addresses #71)
• Salmon help has been made (hopefully) less confusing (addresses #72)
• Salmon invoked with no options now prints the help message (addresses #73)
• Salmon's different help menus now have consistent return codes (addresses #74)

Bug fixes

• Fixed a bug that would cause Salmon to crash when setting --incompatPrior to 0 in alignment-based mode. Thanks to @zhangchipku for reporting this and providing a test case. Further, the behavior of --incompatPrior 0 has been modified in both alignment and read based mode to be more consistent with the behavior one might expect (i.e. fragments aligning / mapping in a manner other than as specified by the library type are completely ignored). Previously, a floating-point precision issue when using --incompatPrior 0 would prevent these fragments from being completely ignored. Additionally, messages concerning zero probability fragments have been summarized to one per thread (rather than one per such fragment).
• Fixed a bug that could cause Salmon to crash when using --seqBias or --gcBias. This bug was triggered only when run on processors with hardware lock elision (HLE) enabled. It seemed to be triggered only on very specific versions of Xeon processors (in conjunction with specific versions of linux distributions). Nonetheless, this bug could trigger a call to unlock() from a thread not owning the corresponding lock, which could lead pthread to segfault. This bug has been addressed by moving the unlock() call and also switching the lock type from a mutex to a custom "tryable" spin-lock, which doesn't exhibit such behavior. Thanks to @nicolasstransky for uncovering and reporting this issue, and providing a test case that would reproduce it (on appropriate hardware).