use supplementary alignments to identify large deletions

[tedsharpe]

No description provided.

[SHuang-Broad]

Ted, I've finished reading the code but I have some questions about the decisions made in findLargeDeletions().
Can you please explain?

[SHuang-Broad]

Hi Ted,
After we talked offline I went back and read the code again.
I still have some questions regarding the method
static Cigar findLargeDeletions( final GATKRead read )

1. It seems this will do redundant work in the following sense: for the same query sequence which has several alignments, each GATKRead (which is actually an alignment record) will be touched by this method, hence imagine one query sequence with two corresponding GATKReads, the current implementation will emit two new GATKReads. Seems unnecessary and double counting evidence.
2. I don't see any check on same-chromosome-ness, i.e. fields[0], which is formatted SA:Z:<CHR_NAME>.
3. I see checking of overlap length on the query sequence between two alignment records, but I don't see a check of gap size on the query sequence between two alignment records. As we talked about this offline, it is a hard problem when the two alignment records are gapped away both on the reference and the query sequence, if you want to merge the two records into a single record.
4. I am still not quite understanding line 1652 about why you are using the clip length to decide orders.
5. Is there a reason to limit the del length to 2, which is the same as the threshold on overlapLength?

For the related method recplaceCigar, the method is not checking for negative values on overlapLength, which judged from int Interval.overlapLength(Interval) is possible.

[tedsharpe]

1. We're only processing primary lines. If there are supplementary alignments we grab those from the SA tag on the primary line.
2. These experiments all have a single amplicon, to which the reads are aligned. All contig names are equal. That there is just one contig is tested on line 681.
3. That is tested on line 1653 and 1661. If the reference coverage isn't properly gapped the deletionLength could be driven negative, and we won't attempt the merge.
4. Because that's where the unaligned part of the read is, the could be "filled in" by a supplemental alignment.
5. It could've been a little larger. We're trying to make sure that it isn't something that BWA would've been happy to merge into a single alignment.

Negative overlap lengths are possible, and accounted for. (A negative overlap is a gap.) Line 1644 takes Math.abs(overlapLen), so a gap larger than 2, or an overlap larger than 2 are both rejected.

I'll fix up the other helpful suggestions tomorrow, after my presentation. Thank you for those.

[tedsharpe]

Comments have been addressed.

[tedsharpe]

done. it bugs me a little because the methods are inefficient, but so be it.

[SHuang-Broad]

👍