What is the mv tag in the output bam file with base modifications?

[caspargross]

I cannot find a documentation for the mv tag in the bam generated by bonito with modbases. The tag contains a very long array with binary values (0,1,0,1,0) longer then the number of bases for the read. This data could probably stored in a more compact way. Can someone tell me what this tag is even needed for?

I have the suspicion that this tag causes IGV to crash (ArrayIndexOutOfBounds Error) on my system. Anyone else experience similar problems? Is there an undocumented flag to not include this tag into the output? What ist the fastest way to remove this from the bams?

[iiSeymour]

The mv tag is the sequence to signal move table for aligning the call back to signal space.

The fastest way to not include this tag is to comment out these two lines.

[caspargross]

thanks!

[joshtburdick]

(Disclaimer: this is all based on my understanding of these things; please let me know if I have something wrong...)

I've sometimes read of people asking how to get the event alignments from the mv tag (and have looked at using that some myself). I have two quibbles with the mv tag in its current form :

• it includes the window size used by the NN / basecaller. This feels to me like an implementation detail, which shouldn't be relevant for users who just want to know where the event bounds are.
• it's long, and not easy to read, e.g. if paging through a BAM file using samtools (which admittedly isn't the best tool to use).

I'm wondering if something like a SAM/BAM formatuint32_t array of "number of samples per event" would work? (or uint16_t might be enough.) (I realize that it's not hard to translate the mv tag into these event lengths.)

I know that f5c has an ss tag which is similar; my humble opinion is that something simpler might suffice.

That would streamline getting event locations, using something like np.cumsum . And if basecallers can eventually just segment the signal into events, then there would already be a tag for that...