Paired end reads with different read lengths

Question

I downloaded some raw RNA-seq reads from NCBI using the sra-toolkit (Accession numbers: SRR2053159-64). The reads were generated using ABI SOLiD, and in colour space. I downloaded them in base space in fastq format using the -B option in fastq-dump. But after that, when I am looking at the data after running FastQC, I find that the forward read length is 50 while the reverse reads length is 35. How is this possible? This is causing all the reverse reads to fail the filtering criteria set in Trimmomatic MINLEN:36. What is the correct way to work around this?

I have already set LEADING:20 TRAILING:20 AVGQUAL:25 SLIDINGWINDOW:10:30 MINLEN:36 Would it be a good idea to entirely remove the MINLEN:36, or would it be better if I make the threshold 25?

Actually I am trying to compare the transcriptomes of different bacteria under a certain stress using raw reads from NCBI. While for the rest of the set of bacteria the sequencing was done using either Illumina or Solexa, this one was done using ABI SOLiD. Is it a good idea to include this ABI SOLiD data along with the others for analysis?

Answer 1

I find that the forward read length is 50 while the reverse reads length is 35. How is this possible?

Forward cycle length was longer on SOLiD than reverse cycle length; this is common for SOLiD data. If you want to work with your data, you'll need to adjust your trimming settings appropriately to account for this (e.g. getting rid of the minimum length entirely, or setting it to a lower value). Trimmomatic does have other trimming options that are not length-based. Given the options that you've mentioned, it should be fine to just drop that minimum length parameter.

Is it a good idea to include this ABI SOLiD data along with the others for analysis?

No, especially not if you're converting to base space, then mapping. SOLiD data should be mapped in colorspace, so that small changes in base transitions don't have a huge effect on the mapped sequence. SOLiD data converted to base space sequence is not appropriate for mapping because it mixes different error modes (i.e. sequencing error, and base transition error). Bowtie (as in Bowtie v1) can map to a colorspace reference, and will correct errors based on that reference in the resultant SAM output. This means that if you trust your reference, you can use Bowtie as a data cleaner for colorspace data.

However, on a practical level, the output of ABI SOLiD machines for existing datasets was low enough that (coupled with the bioinformatics issues) it makes more financial sense to resequence samples than to try to navigate around the pitfalls of colorspace representation.

I have previously offered the following steps for dealing with colorspace data:

1. Transfer all the colorspace files onto an external hard disk
2. Delete all other copies of the colorspace 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

A More detailed Explanation

[from here]

In colorspace sequences that are converted to base space, any error in the sequence will cause all the following bases to be incorrect. Any colour-space to base-space conversion needs to take into account (and correct) errors so that the base-space sequences are correct. When there is a sequence difference, the conversion needs to make sure that only that position is changed in the base-space version.

Consider the following sequences that map to the same position:

reference: G101320112
sequence1: X101120112
sequence2: X101312011
sequence3: X201320312

[I chucked an INDEL in there to make things a bit harder]

A naive base-space conversion would convert these sequences as follows:

reference: GTTGCTTGTC
sequence1: GTTGTCCACT
sequence2: GTTGCAGGTG
sequence3: GAACGAATGA

[apologies if my conversion is incorrect. Fixes appreciated]

Very similar colour-space sequences, but very different base-space sequences.

A more correct conversion would notice where the errors were in the sequences relative to the index, and modify the next colour-space base as well to something that looks appropriate:

reference: G101320112
sequence1: X101100112
sequence2: X101313011
sequence3: X231320332

This would end up with these converted sequences:

reference: GTTGCTTGTC
sequence1: GTTGTTTGTC
sequence2: GTTGCATTGG
sequence3: GATGCTTATC

Which look considerably better.

I hate colorspace because the conversions are very unintuitive, and difficult to explain to other people. About the only nice thing is that reverse complement is just the reverse, but this also means that aligners and assemblers need to be modified to account for that when working in colorspace (or double-encoded colorspace), and you can get weird unexpected chimeras (e.g. poly-A tails and poly-T heads merging). You can save a lot of pain and confusion by sticking with a base-space sequencer.