GGc.G problem with Solexa data

[BaCh]

Dear all,

(Note: the data I'm talking about came from a GAII and, if my assumption is correct, used a 36mer kit to read 40 bases.)

I've been working on a number of projects with Solexa data (bacterial resequencing including hand editing to get "100% certain" SNPs). Looking at cases where the programs report "there's a problem, we're unsure about the true situation", I've made the following observation:

In read direction, errors like to occur directly after GGC.G (the dot standing for any base). On a broader scope, GG..G is at risk.

There are probably other factors as fortunately this does not occur everywhere in the genomes I'm working on, but when this problem strikes, it easily affects 1/3 to 1/2 half of the reads, sometimes more. Also, the problem is more likely to occur in the second half of the read than in the first half.

I've attached a small screenshot of a typical case as example (the yellow C being correct, the blue Gs not).

Now, I have some routines that can filter out problematic cases, but then I loose on rare occasions almost the entire coverage. Not good.

Questions:

1. Has anyone else seen this?
2. Any idea if this can be reduced (I suppose more on the lab side)?

Regards,
Bastien

[bioinfosm]

What are you using to do the alignments? How do you identify 'cases' or mis-calls?

[dvh]

I had a look in our data, we dont seem to see this. GAII 45bp or 70bp x2 PE. Human resequencing. Novoalign.

[BaCh]

Originally Posted by bioinfosm

What are you using to do the alignments? How do you identify 'cases' or mis-calls?

I use MIRA. I've put together a walkthrough using public data (all from the NCBI) that shows the problem and gives a step by step recipe to reproduce what I see in several projects:

http://chevreux.org/GGCxG_problem.html

Disclaimer: yep, MIRA may be slow at times and can be a real memory hog. But it's mine and does exactly what I need