Problem with SOLiD data

[Alessandro1976]

Hi everyone,
I'm trying to analyze small RNA data from SOLiD using both Lifescope and a different pipeline which uses miRDeep2.
I converted the XSQ files into FASTQ files with the XSQ tools, then I also ran Lifescope and got the BAM file with the mapped sequences.
However, when I try to compare the reads from the FASTQ file and the reads extracted from the BAM file, they are completely different.
For example, the two following entries are from FASTQ and BAM, respectively:

@Library43:559_548_933/1
CGGTGCAGGGACGAAATACAGTTAGACATATCTC
+
@@@@@@@@@@@@@@@@@6@@@@6@@@@/@@;@/@

559_548_933 0 chr9 23209018 1 21M14H * 0 0 CAGATCAAGAGGTCCCCGGTT JJJJJJJJJJJJJJJJJJJJJ RG:Z:Library43_11 NH:i:10 CM:i:0 NM:i:0 CQ:Z:@@@@@@@@@@@@@@@@@@6@@@@6@@@@/@@;@/@ CS:Z:T21223210222012000301023302010303131


The IDs are the same (559_548_933), but the sequence in the FASTQ file (CGGTGCAGGGACGAAATACAGTTAGACATATCTC) is completely different than the one in the BAM file (CAGATCAAGAGGTCCCCGGTT). It's not just a matter of trimming the adaptor sequences, the sequences are just different overall.
Also, when I try to map the reads from the BAM file with either miRDeep or Tophat I have a high percentage of success, when I try the same thing with the FASTQ file I have 0% of mapped sequences.

Does anyone know why there is such a difference between reads with the same ID and what the FASTQ file reads actually are?

[ShaunMahony]

Hi Alessandro1976,

You can't convert colorspace reads (e.g. from SOLiD) into sequence space with any degree of accuracy. Since colorspace bases are defined relative to the previous base, sequencing errors are propagated through the rest of the read. It's explained well here:

http://seqanswers.com/forums/showthread.php?t=16115

[gringer]

Programs that map colour-space are likely to also correct the reads when reporting the sequences in the BAM files (I know bowtie does this, and it makes sense for others to do this as well). The indexes that are mapped against must be in colour-space, and there are a few nice error-correction features in colour-space that mean it can be easier to distinguish between sequence changes and instrument error (e.g. a SNP needs two adjacent colour changes).

However, you will always run into issues when trying to interpret or compare the results of a colour-space run (e.g. in a genome browser) because colour-space is a completely different beast to base-space and doesn't make sense to humans -- see the post ShaunMahoney linked to for more details. Here's my recommended approach for carrying out such a comparison:

1. Transfer all the colour-space files onto an external hard disk
2. Delete all other copies of the colour-space files
3. Remove the hard drive from the computer
4. Use a sledgehammer or similar to squash the disk platters closer together
5. Withdraw $500 from the bank
6. Place the $500 on top of the hard drive
7. Return the hard drive (with the money) back to the client
8. Report to the client that there was insufficient data for a suitable analysis, and recommend that the experiment is repeated using a base-space sequencer

[Brian Bushnell]

Agreed.

Colorspace was a terrible design decision, and the fact that colorspace data persists wastes a lot of people's time and energy. It will always give inferior results in anything other than purely quantitative analysis like chip-seq. But, because of Solid's high error rate, it will give inferior results there, too.