PointFinder frameshift adjustment

[Sam Chorlton]

Thanks for the amazing tool. We’re struggling with getting PointFinder working on assembled Neisseria gonorrhoeae nanopore sequencing data. There are obviously lots of frameshifts in the data. I’m just wondering if PointFinder is keeping track of the codon numbers correctly (I see from the source that there is some complicated tracking of codon numbers).

Assembled contig, as well as BLAST xml file attached. We expect an F at AA position 91 instead of the reference S in gyrA. PointFinder does not call this mutation. Upon investigation, at nucleotide 144, there is an insertion in the assembled contig.

Codon 91 is then an F in both reference and assemble:

Deleting the A and the - on the contig and reference, respectively, restores the frame, and I can see from my BLAST alignment that indeed, AA 91 reference is now an S and mutated.

Looking futher, it seems that not accounting for the frameshift, PointFinder identifies a premature stop codon at AA 66 halting the search beyond there. Any insight would be much appreciated…thanks!

[Alfred Ferrer Florensa]

Dear Sam Chortlon,

Thank you for notifying this. I will take a look at this major bug.

Is the stop codon at AA 66 found with or without the insertion at the nucleotide 144?

‌

Best,

Alfred Ferrer Florensa

[Sam Chorlton]

I believe only with the insertion.

[Alfred Ferrer Florensa]

I understand then that PointFinder is not reporting the mutation desired because the insertion, as it happens before the premature stop codon and and the desired mutation. I am not sure this is a major bug, but I agree a more detailed explanation of the effects of a frameshift in the data analyzed would be better. We will add it in our next major update.

Is there anything else that do not work?

[Alfred Ferrer Florensa]

ResFinder now has the ability to ignore premature stop codons

[Alfred Ferrer Florensa]

Solved as it is provided an option for ignoring stop codons