-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mateIsFwd never gets a value set for unpaired hits #46
Comments
In the SAM output of RapMap, there was an implicit assumption that if a read is unmapped, then the read is written down in the forward orientation. That is, if the read unmapped flag is set (0x4), then the flag 0x10 was assumed to have an invalid (random) state --- the unmapped read is always recorded in its forward orientation. However, while the SAM spec does dictate that many of the flags can be ignored (i.e. are not guaranteed to be valid) if 0x4 is set, it actually doesn't seem to make this claim about 0x10. These changes should assure that, for an orphaned pair, the mateFwd flag will be set.
Hi @jenni-westoby, Thanks (again) for finding this and bringing it to our attention, and for the brilliantly-detailed bug report. Perhaps there are a couple of reasons this evaded us. The big one, I think, is that when the mate is unmapped, we internally assume that none of its flags are really meaningful. It seems that, while this is valid for many flags (SAM spec, section 1.4, bottom of page 6), it's actually not true for the 0x10 flag --- this should still take on a meaningful value. We'd simply been assuming that if a read is not mapped, it is written down in the orientation in which it appears in the input file (i.e. always forward). I've pushed a commit to the The downside of fixing it on this branch, means that I can't immediately check the fix against your example (because the read is properly paired). So, I'll leave this issue open for the time being until we can ensure that my fix actually works. Thanks again! |
Thanks for the speedy response! And apologies for not having a test example that worked for |
In RapMap v.0.5.0, the value of mateIsFwd is never set for unpaired hits in the function mergeLeftRightHits, in the file include/RapMapUtils.hpp. The function in question is below
The problem occurs because in the final else if (leftHits.size() + rightHits.size() > 0 and !tooManyHits) statement, hits are appended to the end of joint hits without updating the unset mateIsFwd field. Instead mateIsFwd is 'randomly' filled with a garbage value which appears to have some dependency on the previous read which was aligned. The value which is assigned to mateIsFwd then has an impact on the SAM flag because mateIsFwd is used to determine the SAM flag in getSamFlags. Consequently, read SRR5237781.4 in problem4_1.fastq and problem4_2.fastq usually produces the following alignment on my machine:
Whereas the same read in problem4_3read_1.fastq and problem4_3read_2.fastq usually produces this alignment (virtually identical except different SAM flags):
This problem does not occur for proper paired hits, because mateIsFwd is correctly set in the if (!(rightTxp < leftTxp)) code block. On the develop-salmon branch, read SRR5237781.4 produces proper paired hits, so this test example does not work (or rather, it does work, because mateIsFwd is correctly set in if (!(rightTxp < leftTxp)) ). Unfortunately I have not yet been able to find as nice a test example for the develop-salmon branch yet, but from reading the code I believe that this might also be a problem on the develop-salmon branch. The fix would be to set the value of mateIsFwd in the final else if statement of mergeLeftRightHits().
problem4_1.fastq.gz
problem4_2.fastq.gz
problem4_3read_1.fastq.gz
problem4_3read_2.fastq.gz
The text was updated successfully, but these errors were encountered: