hisat2 / bowtie: read has more quality values than read characters

Question

[juan.crescente]

I'm struggling with this issue:

./hisat2 -x ../../data/index/hisat_2/iwgsc -U ../../data/mrcv/genes/21dpi_C_R1.fq.gz,../../data/mrcv/genes/21dpi_C_R2.fq.gz,../../data/mrcv/genes/21dpi_C_R3.fq.gz,../../data/mrcv/genes/21dpi_C_R4.fq.gz,../../data/mrcv/genes/21dpi_T_R1.fq.gz,../../data/mrcv/genes/21dpi_T_R2.fq.gz,../../data/mrcv/genes/21dpi_T_R3.fq.gz,../../data/mrcv/genes/21dpi_T_R4.fq.gz -S ../../data/mrcv/genes/alignment/21.sam --un ../../data/mrcv/genes/alignment/21UN.sam -p 6 

Error: Read J00113:78:H3JKNBBXX:3:2209:5670:2281 1:N:0:CGATGT has more quality values than read characters.
terminate called after throwing an instance of 'int'
Aborted (core dumped)
(ERR): hisat2-align exited with value 134

Scythe was used to remove adapter contamination and Sickle to remove low-quality reads.

I'm using HISAT2 version 2.1.0 on Ubuntu 18.04. Any ideas what could be wrong?

[Bastien Hervé]

Could you show the record (header, sequence and quality) J00113:78:H3JKNBBXX:3:2209:5670:2281 1:N:0:CGATGT in your post please

[ATpoint]

Cannot really comment on hisat2, but I had this problem with BWA mem sometimes, and it always was a memory problem. How much RAM do you have available? HISAT2 is actually not very memory-consuming, not sure if this is the problem. Also, agreed with Bastien, check if indeed SEQ and QUAL are different for J00113:78:H3JKNBBXX:3:2209:5670:2281 1:N:0:CGATGT.

[juan.crescente]

I have 32 GB of RAM.

The line seems fine:

@J00113:78:H3JKNBBXX:3:2209:5670:22819 1:N:0:ATCACG
CCATGATCTTAGTTTCTGGCGCTCGTTCGTCGCGAAATAAGCCGAGGTGT
+
<AFFFJJJJFJJJFJJJJJJJFFJFJFFJJJJ7<JAJFF<FJJJ<JJ7F<

Increasing swap would be a solution? Running each file separately instead of all at the same time seems to work until now, I'm still trying to figure out what to do next when alignments are separated. Im adding read group labels into each.

[Bastien Hervé]

It's not the good record, primers are different CGATGT ATCACG

[juan.crescente]

you're right!

@J00113:78:H3JKNBBXX:3:2209:5670:2281 1:N:0:CGATGT
CTCGGAGCCACTCTTGGCCTCCCGGGAGCTGATGTAAGGCCCTTAGGGAA
+
AAFFFJJAJJJJJJJJGGCGTGTACCAGTTTGTAGACAAGTACGGTGCCAACGTCGACGGCTAC
+
AAFFFJJJJJJJJJJJJJ1TGT
TTCCCTTTJJJJJ1TGT
TTCCCTJJ

Indeed the record seem odd!

[Bastien Hervé]

Thus, I let you investigate Scythe and Sickle log files to find out what happened

[ATpoint]

Are you pipe the output into a sorting tool that might take up some memory?

[juan.crescente]

I don't. This is the command I'm using

 ./hisat2 -x ../../data/index/hisat_2/iwgsc -U ../../data/mrcv/genes/21dpi_C_R1.fq.gz,../../data/mrcv/genes/21dpi_C_R2.fq.gz,../../data/mrcv/genes/21dpi_C_R3.fq.gz,../../data/mrcv/genes/21dpi_C_R4.fq.gz,../../data/mrcv/genes/21dpi_T_R1.fq.gz,../../data/mrcv/genes/21dpi_T_R2.fq.gz,../../data/mrcv/genes/21dpi_T_R3.fq.gz,../../data/mrcv/genes/21dpi_T_R4.fq.gz -S ../../data/mrcv/genes/alignment/21.sam --un ../../data/mrcv/genes/alignment/21UN.sam

thanks for the help

Answer 1

[juan.crescente]

I could verify with

gzip -t R2.fq.gz && echo ok || echo bad

that the file was corrupted. For some reason the reads were not in the correct line. Re-downloading the file solved the issue.