CIGAR inconsist with read length. Does Bowtie2 reedit read sequence?

[wisense]

Hi, guys

I used bowtie2 to align paired-end reads to hg19 genome, and got the sam format output. Then when I tried to convert the sam into bam, I found some error information:

[samopen] SAM header is present: 25 sequences.
Line 817574, sequence length 124 vs 125 from CIGAR
Parse error at line 817574: CIGAR and sequence length are inconsistent

So, I looked into the sam file, and found the line 817574 is like:

HISEQ04:185:C62CTANXX:3:1101:8017:19749	99	chr2	184686606	42	125M	=	184686727	246	TAGAAAAACTAAACAATGAACCGATAAAAAAACTACAACAACTTTTTAAGACGTAGATAATATAATACAATGTAAATAGAATCAACAAAAATTTTTTAAAATGAATGGTAAGAAAGGATTATTA	BBBBBFFFFFFFFFFFFFFFFFFFFFFFF<FFFFFFFFBFBFFFFFFFFFFBFFFFFFFFFFFFBFFFFFFFFBFFFFFFFFFFFFFFFBFFFFFFFFFFFFFFFFBFFFF<F7F<FFFF<BF<F	AS:i:0	XN:i:0	XM:i:0	XO:i:0	XG:i:NM:i:0	MD:Z:125	YS:i:0	YT:Z:CP

The CIGAR is 125M, which means the read is 125bp and each base is match/mismatch, while the read sequence is only 124bp. As I know, my paired-end reads are 125bp in sequencing. I think bowtie2 has reedited the sequence of the read, so I compared the sequence in the original fastq file and the bowtie2 alignment:

Seq in Fastq:
TAGAAAAACTAAACAATGAACCGATAAAAAAACTACAACAACTTTTTAAGACGTAGATAATATAATACAATGTAAATAGAATCAACAAAAATTTTTTAAAATGGCACGATGAAGTTAAGGCATAG
Seq in Bowtie2 alignment:
TAGAAAAACTAAACAATGAACCGATAAAAAAACTACAACAACTTTTTAAGACGTAGATAATATAATACAATGTAAATAGAATCAACAAAAATTTTTTAAAATG[COLOR="Red"]AATGGTAAGAAAGGATTATTA[/COLOR]

It's quite strange the tail bases of the sequence in the alignment are quite different from the fastq file. Somebody know how do this happen? Does Bowtie2 reedit the sequence when it align the read to the reference?

If you have any idea, please reply me, thanks~
wisense

[Brian Bushnell]

It sounds like the sam file got corrupted somehow; I'd suggest re-mappping. And, perhaps, upgrading to the latest version first in case that was a version-specific bug.

[wisense]

It sounds like the sam file got corrupted somehow; I'd suggest re-mappping. And, perhaps, upgrading to the latest version first in case that was a version-specific bug.

Hi, Brian
Thanks for your reply.
My Bowtie 2 version is 2.2.4, I will try the latest version 2.2.5 to see if there's any difference. By the way, there're about 33437 alignments in the sam file their sequence lengths are not 125bp, maybe ranging from 80-120 bp. Quite strange to me.

[Brian Bushnell]

It sounds to me like two processes ran at the same time, one with 125bp reads and one with variable-length reads, and were writing to the same file... just a guess. I suggest you confirm the read count and length distribution of what you think was the input fastq - should be the same as the output sam. The BBMap package has a tool called readlength.sh that you can use to do that quickly.

[wisense]

It sounds to me like two processes ran at the same time, one with 125bp reads and one with variable-length reads, and were writing to the same file... just a guess. I suggest you confirm the read count and length distribution of what you think was the input fastq - should be the same as the output sam. The BBMap package has a tool called readlength.sh that you can use to do that quickly.

Before bowtie2 alignment, I used FastQC to analyze the paired-end reads and both read1 and read2 fastq are 125bp, not with variable-length. BTW, I have used the latest version of bowtie2 (v2.2.5) to re-align the reads to the genome, there's no such error in the alignment. Perhaps, this is a version-specific bug of bowtie2. Thanks for your good suggestion.

[dpryan]

This is either a very very obscure bug or, more likely, Brian guessed correctly that you have two processes overwriting each other's output (or something along those lines). You might just rerun the alignment.