Closed rhysnewell closed 2 years ago
Which OverhangStrategy
is this using? I know that OverhangStrategy::Ignore
can return a longer alignment (I think this is the relevant code). Also, related to that, the return offset in Align
should be isize
, not usize
, but I think you're already handling that.
If you can get a test case I'm happy to look into it.
Okay, I don't think this is a problem with the actual algorithm implementation at all. I think this might be a C memory issue. The problem is only reproducible when you are performing multiple alignments in parallel. See https://github.com/rhysnewell/Lorikeet/blob/master/tests/smith_waterman_aligner_unit_tests.rs#L406
This test incorporates several test alignments using the basic smith waterman aligner and the gkl implementation across a number of alignment parameters and overhang strategies. I noticed that when running these alignments without using rayon, the tests never failed. The results would always be the same between the two alignment methods. As soon as I wrapped the whole thing in a rayon parallel iterator the started failing very consistently, with the gkl aligner giving completely different alignments than the standard implementation:
cargo test --release --test smith_waterman_aligner_unit_tests
test test_avx_mode ... FAILED
failures:
---- test_avx_mode stdout ----
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
left: `Some([Match(18), Ins(879), Match(398)])`,
right: `Some([Del(6), Ins(427), Match(9), Ins(89), Match(4), Ins(64), Match(3), Ins(15), Match(5), Ins(283), Match(396)])`: Alignments are not equal:
Some([Match(18), Ins(879), Match(398)])
Some([Del(6), Ins(427), Match(9), Ins(89), Match(4), Ins(64), Match(3), Ins(15), Match(5), Ins(283), Match(396)])', tests/smith_waterman_aligner_unit_tests.rs:446:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
test_avx_mode
Additionally, sometimes the test would just hang indefinitely suggesting that there is a sporadic deadlock somewhere too.
I had no idea that using rayon would cause an issue like this, but I suppose it makes sense? I'm not sure how you would hunt down a fix for this. Hopefully the stable rust implementation will fix this bug. Pretty interesting interaction though, maybe play around with the test and see if you see the same thing. Definitely fails very consistently for me when in parallel, but safe single-threaded
That might be the fault of this global variable.
That would be great, thank you!
Published 0.1.1
Hi Phil,
I've been getting this set of errors in Lorikeet when using gkl-rs to perform the smith-waterman alignment. It seems that ocassionally the alignment produced by gkl-rs will produce a CIGAR string that suggests that the read aligninment ends up extending past the reference. I don't have specifics nor a reproducible test case yet, but just wanted to flag it with you.
Here is an example error produced by Lorikeet when using gkl-rs:
This error disappears when I use my basic smith-waterman implementation. The annoying thing is that this is not picked up in the test cases, everything is green and good apparently. But yeah, seems like gkl-rs is adding either additional Matches or Deletions since the reference ends up needing to be longer for the alignment to make sense.
Cheers, Rhys