[Richard Finney]

Hey, thanks for figuring out that it was CCGG . I thought it might be something like that. It must be that a certain distance into the read if the CCGG happens it starts stuttering. I see that it is quality "masked" but that the "bad quality mask" is short by about 2-3 bps. The bad call is often in that "good quality" area, in the data I look at. The "snp call must have enough evidence in both directions" rule should save the day.

[Michael.James.Clark]

I also talked to more people about this issue and the answer is that this is a well-known issue when you have a specific tetramer (CCGG, if I remember correctly) that ends up causing bases to be skipped.

This explains why the differences are strand specific and why it happens in very specific places in the genome (including in completely different labs). The reads generally end up being clipped soon after because the indel, but there are cases that are repetitive enough that the few other bases match by chance, leading for the trimming to occur later and the read to be kept.

I'm not quite sure where would be best place to recognize this corner case and deal with it, but in my case I'll take the lazy way out and just filter them out at the end.

Thanks for all who offered suggestions.

Ah yes! I recall a thread discussing that very issue here a while back now that you mention it. Like Richard suggested, insisting that there be evidence for the call on both strands will generally get rid of these, thankfully. (Edit: Maybe that thread wasn't here, as I can't seem to hunt it down. If anyone remember it, link us up!)

[csoong]

Thanks for all the detailed responses!
Could anyone further explain the difference of an early CCGG vs a late one? At the program level what is happening here?