Closed TDMedina closed 5 years ago
Fixed in pull request #69 Problem was in mate fetching. Our old criteria for mate matching was:
If a mate is unmapped, it is assigned the same start pos as its mapped mate. This means when we mate fetch using the pnext, we will get both the unmapped mate and mapped mate, which both satisfy the above criteria. So, sometimes we fetch the same read again, which is then removed in the uniqifying step, resulting in a missing mate and uneven FastQ outputs.
Added the following criteria in beta pull request 69 to identify true mates:
Noticed in validation set chr6 variant. According to current build, there should be 480 reads in each output FastQ for a total of 960 reads. However, the R1 has 480 and the R2 has 479. The missing read appears to be the only unmapped read, so there could be an issue there.