Does bowtie2 die everytime the first base quality of a read is @?

Question

[top1214]

Genome updated, only have bam files, so reversed engineered bam to fastq with samtools. Realigning to the new genome build with bowtie2 with no special flags.

I get an error message like:

Error: Read <@DDD?D?@CFFE@4C@FFH@?+CHFGFBBBG*C;DFIEEFFB@BF@FEFFB=BFFECFA=CEEEIFCFFFB;;7;3?>>BBCC5>?;(,,2/2 has more read characters than quality values.
libc++abi.dylib: terminating with uncaught exception of type int
(ERR): bowtie2-align died with signal 6 (ABRT)

But then I check out that line, and it's the quality calls for a read. I changed the @ to A (one step up on the quality scale), and that solved the problem. For that read. A new read also has this problem. Is this really a systemic problem?

[pengchy]

Which version of bowtie2 produced this error, has the latest version of bowtie2 resolved this bug? I produced the same error using bowtie2-2.2.4.

Answer 1

[WouterDeCoster]

The error is fairly specific, it states that you have more read characters (nucleotides) than you have quality values. How did that read look like? Can you share?

[harold.smith.tarheel]

This error should indicate the sequence identifier as Read but (as the OP states) it's actually showing the quality values, which suggests that the phasing is off. If so, the following lines are read identifier (misread as sequence), sequence (misread as '+' character), and '+' (misread as quality) - which would result in the observed error message about read characters > quality values.

I don't use Bowtie2 but, given it's popularity, this behavior probably would've been reported as a bug if observed by others. Have you checked your FASTQs to confirm that they're constructed correctly?

[top1214]

Yeah. Like I said, I changed the @ character to an A, and it didn't stop at the same place. It stopped at a new place. The new place is another quality score that starts with an @.

[top1214]

@HW-ST997_0090:3:1101:10801:115070#0/2 TGTATACTCCATCAGCTGTTTTAGTTTCTGTTGTTTTTGACTGTTTGTCTCCATCTTGTGTCTGAATAATGCGCAGGTTAGTGTATACTCCATCAGCTGTT + @C?DDFFFHHHHHJJJIIEHIJHGHGJJJJIGI@FEGIGGIIJHHGGHJIGHIIIJIGGGIEGCFGICIGDHGIEED?CDFEDEDEFEE@CCC@CCDDD:> @<@DDD?D?@CFFE@4C@FFH@?+CHFGFBBBG*C;DFIEEFFB@BF@FEFFB=BFFECFA=CEEEIFCFFFB;;7;3?>>BBCC5>?;(,,2/2 @HW-ST997_0090:3:1101:10801:116424#0/2 TGCTCTAGGCTAGCTTTTAACAGCAGATGATGCTCTAGGCTAGTTTTTAACAGCAGACGGTGCTCTAGGCTAGTTTATAACAGCAGACGGTGCTC + ?;;:DD;::2ABFBAFGIIBBHDEA>;F><F9*1:9??F>D?@9HBBD;D9B<DHEEA<A4648=).@CHB;=?ACD;).;BAAA@(538;A/:3

Which means this one is an error in my parsing. Gah.

[WouterDeCoster]

Perhaps one of the following can help?

bedtools bamtofastq http://bedtools.readthedocs.io/en/latest/content/tools/bamtofastq.html

Picard samtofastq https://broadinstitute.github.io/picard/command-line-overview.html#SamToFastq