-
Notifications
You must be signed in to change notification settings - Fork 3
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
Issue with reporting resistance OXA-48 #149
Comments
Currently blocked by installation issues |
No longer blocked, installation issues solved in #142. |
Will be resolved in Clinical-Genomics/CG-JASEN#5 |
Re-opening this, as it continues to cause problems, and we might need to prioritize it if Jasen is not completed soon. |
I have been running Spades (4.0.0) assembly + Blasting against the resfinder DB semi-manually, using the same commands as used in microSALT, both with and without the This thus strengthens the suspicion that the error might be in the scraping logic. (Unless there are some differences between Spades 3.13.1 used in microSALT right now, and 4.0.0.) |
Tested this also with Spades 3.13.1 with the same result, so that is apparently not the issue. |
I have now confirmed that an existing OXA-48 is removed in this part of the code (for cleaning up overlapping hits): microSALT/microSALT/utils/scraper.py Lines 344 to 410 in 2f8b19e
Perhaps there is an overlap with OXA-566 ... we'll see. |
And in one of these commits: deed81b Removed newline char in log |
It is introduced with this one: 395a218 Locilengths now ignores reference name (Tested by cherry-picking the commits one by one into a test branch, using a real-world resistance blast output containing both OXA-566 and OXA-48 instead of the test one, and looking for occurrences of |
This needs to be follow up with additional checks The same change might need to be done for other matching as well.
This needs to be follow up with additional checks The same change might need to be done for other matching as well.
This needs to be follow up with additional checks The same change might need to be done for other matching as well.
This needs to be follow up with additional checks The same change might need to be done for other matching as well.
I think I'm starting to have a reasonable test now, that now fails (before implementing the fix), saying: > assert "blaOXA-48" in genes
E assert 'blaOXA-48' in ["aph(3')-III", 'ant(6)-Ia', 'blaOXA-566'] (See https://github.com/Clinical-Genomics/microSALT/actions/runs/9898158769/job/27344305202 ) This is triggered by using some real-world example data where both OXA-48 and OXA-566 are included. But re-assuring to see that we reproduce the inclusion of blaOXA-566 there, as the issue described. And, with the fix implemented, this test passes. |
Describe the bug
Perfect matches to OXA-48 are no longer reporter in microSALT, instead microSALT reports OXA-566 resistance of lower %identities.
Message from KS in Ticket 722237:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
OXA-48 should be reported if this resistances has higher %identity.
Additional context
Is OXA-48 in the raw blast results?
Adding some of the commits made during the period below. Has any affected OXA-48 reporting? Scrape_blast changes likely.
Scrape_blast: Added padder safety
The text was updated successfully, but these errors were encountered: