Potential limitation of fragment size

[mengzhou]

The fragment size of a pair-end alignment is returned by this function as an int. Of course in most cases this would be sufficient, but sometimes we might need a very long fragment. Just to keep a record for future usage.

[bdecato]

A quick change to a size_t type would increase the maximum from 32767 to at least 65351. Not a fix, but after speaking with @rishvanth-kp it seems this would handle most nanopore reads.

WALT is also future-proof for nanopore by allowing mismatches in terms of percentage of the read length, rather than absolute number. This is useful because as the read length increases, the probability of ambiguous mapping introduced by allowing more mismatches will decrease.

And of course, it is unlikely we will ever need to use WALT for nanopore anyway, since hopefully we will be able to distinguish mCpG from CpG based on electrical signal. But I could see that signal being converted to a T or U for mapping purposes.

Is there a situation where we would use WALT or update it with reads longer than 65kb? I feel like a greedy partial-exact-matching approach of some kind would be preferential to 26bp seeds in that case.

[acgtun]

• int len could be negative, maybe it is better to change it to long or long long in C++.

• For nanopore reads, it may need to develop new algorithm to handle some specific concern of long reads, not sure yet

• in the current version, as i remember, as long the read length is less than 2^32, it should be OK.