Move insertions to expected locations

[donkirkby]

If there are substitutions near an insertion, bowtie2 can get confused about where exactly to put the insertion. Use the same technique as Recall to move the insertions to expected locations. Here's Conan's description:

For PR/RT (in recall we do them together), they are at amino acid position 35, 41, 99, 168 (69 of the RT). Most of the time it's just 35 of the protease or 69 in the RT.

For Integrase, there is one insertion at 288, which is a bit weird because it happens right before the stop codon. It doesn't cause any resistance (that we know of), and it's pretty random in size.

I shift them up to 13 nucleotides in either direction.

[donkirkby]

Richard H. says we can drop position 41, so it doesn't conflict with position 35, nearby.

[donkirkby]

We think some samples with deletions are reporting fewer deletions, because the deletion gets closed over when reads start or end near the deletion.

It might be helpful to build a model of expected amino acids at each location in each region, then adjust the location of insertions and deletions to see which alignment better matches expectations. This might be related to the work from #370 that moved deletions to codon boundaries.

It might also be helpful to add a deletion when a read has mapped across a deletion in the consensus. Jeff K. suggested it might be better to pull the deletions out of the consensus instead of leaving nucleotides from the original seed in there. We also discussed generating de novo consensus sequences, instead of using known references.

How would we measure success? Put in synthetic data with known deletions or insertions, then compare how many reads match the expected output with different strategies. Use samples from the 29-MAY-2017.M01841 run. They are all PR-RT projects with non-B subtypes or -INS or -DEL in the name. Rob created a document with more details on what is expected to be in each sample: macdatafile/PRI_VALIDATION/NON-B_and_INDELs/PRI_INDEL_locations.xlsx.

[donkirkby]

Another wrinkle to consider: sweeping insertions and deletions together when they cancel each other out. As an example, look at the NEG-HCV_S127 sample from the 17-Mar-2017.M04401 run. Its V3LOOP coverage under MiCall v7.7 shows a partial deletion in codon 20. However, the Gotoh alignment shows a partial insertion a couple of codons before that.

The G2P score ends up being correct, because it only uses the alignment to decide where to trim the read and ignores the internal alignment details. The nuc.csv and amino.csv reports are incorrect, however. They show the partial deletion and a couple of codons are out of frame.

Be careful with that sample, though. We think the samplesheet was wrong on that run, or the tags were wrong. That negative sample looks like it used the MIDI primers, even though it's labelled HCV. It's also very low coverage, so it might be helpful to look on another run for an actual V3LOOP sample that has partial deletions and see if there's a partial insertion nearby.