Adding an option for genome-based m6a coordinates for the extract flag --m6a

[mtcicero26]

• Currently, --m6a reports the read-based coordinates for m6a residues, but it would be helpful if I could add a flag that would output the genome-based ones instead of or as well as the read-based ones.
• The benefit here is to be able to generate much smaller files for input into FiberHMM, which requires genome-based coordinates. Currently, FiberHMM requires the full --all output, which generates very large files with a lot of information that is not necessary for footprinting.

[mrvollger]

--m6a already reports the reference coordinates which can be changed with the --molecular flag and then back again with --reference. So I don't understand or am missing something about the request. https://fiberseq.github.io/fibertools/help.html#ft-extract

[mtcicero26]

Sorry, I didn't realize that.

[mtcicero26]

Ok, actually, the issue is that the output for the ref-m6a column in --m6a is inconsistent with --all.

For example: An example read which maps from chr2L:1602-9209

• --reference 0,1,2,8,13,15,18,25,33,36,39,41,47...
• --molecular 0,1,2,8,13,15,18,25,33,36,39,41,47...
• --all 1603,1604,1610,1615,1617,1620,1627,1635,1638,1641,1643,1649,1651,1654,1655,1657,1659,1661,1663,1668,1677,1685,1687,1691,1697,1699,1701,1703,1705,1707,1709,1712...

The chromosome, start, and end columns look correct for --r, but it seems like --all adds the start coordinate onto the m6a coordinates. Based on inconsistencies between the coordinates provided by --reference and --molecular, I think it is correctly adjusting the position for gaps etc. in the alignment.

This is fine, assuming the -r coordinates are indeed equivalent to --all ref_m6a outside of the addition of the start coordinate, and I can account for it in FiberHMM when someone uses that as the input. I do think it might be better if the outputs were consistent though?

[mrvollger]

BED12 format specifies that you use the offset from the start specifically in that column, so to maintain compatibility we cannot change this. The reference offsets plus the start should be the same as the --all table since we do account for gaps in the alignment. If you find this isn't the case anywhere you are welcome to reopen.

[mtcicero26]

Ok, great, that makes sense. I'll account for that in FiberHMM.

[mrvollger]

It would probably be good if FiberHMM took BED12 since that is a standard format in case you ever want to use m6As from another caller.

Alternatively you may consider using our experimental python api for fibertools, py-ft, that can directly extract this info for you.