Solid2FASTQ

[Martin R]

Hello

I just got a question. I wanna align SOLID data with BWA and therefore transformed it in FASTQ files with the solid2fastaq.pl script. But the script does not take the whole sequence of the csfasta but excludes the first two bp. In my opinion it would make sense to exclude the first base, as it is not in color space but not two.

Here an example:
an entry of my csfasta files has following sequence
>1_3_123
T000111222333

and the output in the FASTQ file is a sequence with:
AACCCGGGTTT

By comparing the sequences it can be seen that two bp are missing:
T000111222333

AACCCGGGTTT

this is because of line 100 in the script delivered by BWA 0.5.7 in the method read1:
$_ = substr(<$fhs>, 2);
This funktions takes the sequence beginning from the 3rd position.

Is there any reason for this or is this an error ?


Thanks for answering
martin

[nilshomer]

Originally Posted by Martin R

Hello

I just got a question. I wanna align SOLID data with BWA and therefore transformed it in FASTQ files with the solid2fastaq.pl script. But the script does not take the whole sequence of the csfasta but excludes the first two bp. In my opinion it would make sense to exclude the first base, as it is not in color space but not two.

Here an example:
an entry of my csfasta files has following sequence
>1_3_123
T000111222333

and the output in the FASTQ file is a sequence with:
AACCCGGGTTT

By comparing the sequences it can be seen that two bp are missing:
T000111222333

AACCCGGGTTT

this is because of line 100 in the script delivered by BWA 0.5.7 in the method read1:
$_ = substr(<$fhs>, 2);
This funktions takes the sequence beginning from the 3rd position.

Is there any reason for this or is this an error ?


Thanks for answering
martin

This is very subtle but important property of BWA: 2bp are lost from each read for SOLiD data.

The first color encodes the adapter and the first base, and therefore is partly dependent on DNA not present in the underlying genome (the adapter). BWA trims the first color and adapter so you lose the first two bases (a 50bp reads is now 48bp). This is performed so when the color read is compared to the encoded reference (in color space), the colors from the read will match the color reference exactly (when there is no error). Including the first color (or adapter) would violate those rules. Nonetheless, you lose two bases from each read, which BWA should be able to include/recover during local alignment (Smith-Waterman/Needleman-Wunsch), but does not. Other software, like BFAST (I am the author), can use all the bases in the final alignment, so it is possible. You should bug the BWA author (lh3) to remove the 2bp base trimming as it is not going to be fixed by changing the solid2fastq.pl, but only through changing much of the BWA color space code.

<rant>
It also seems like SOLiD support is an afterthought of many alignment software authors. Such a shame, since it is a much more fun and challenging problem to try and properly align in color space.
</rant>

[KevinLam]

Originally Posted by nilshomer

<rant>
It also seems like SOLiD support is an afterthought of many alignment software authors. Such a shame, since it is a much more fun and challenging problem to try and properly align in color space.
</rant>

hahah agreed.. is <rant> a new BB code? ROFL

[Martin R]

Thank you very much for that fast answer.
Now I understand the handling of neglecting the first 2bp.