Hisat2: Differing amount of reads in mates

[ronaldrcutler]

Hello all,

I am aligning paired-end reads using Hisat2. Unfortunately, some of the fastq files were corrupted in transfer. I was able to recover them using a gzip recovery protocol, but was left with about half the data. I have previously used Tophat2 to align these "recovered" fastq files, but am getting this error when trying to align with Hisat2:

Error, fewer reads in file specified with -2 than in file specified with -1

How is Tophat2 dealing with this differently than Hisat2?

To fix this, I am trying repair.sh from the bbtools package to keep the reads that do have pairs in both files and output singletons to a seperate file and then try using all three with Hisat2.

Although I can't seem to find reference to this error anywhere else, any advice on how I should deal with this?

[GenoMax]

Don't use paired end reads with unmatched pairs since that can lead to erroneous discordant alignments. repair.sh is the way to go.

[ronaldrcutler]

Thanks Genomax. I would assume in the Tophat2 run with these "recovered" files there were erroneous discordant alignments that would be discarded and not affect overall alignment.

I was successfully able to run Hisat2 following repair using the new paired-end files, including the singleton file. A high percentage of the singletons mapped uniquely - surely these are not erroneous alignments?

[dcameron]

Firstly, since the underlying issue is a data corruption issue, I would strongly recommend you re-download the corrupted data. As it is, your results will be not be reproducable from the original data.

A high percentage of the singletons mapped uniquely - surely these are not erroneous alignments?

If only one of the .1.fq.gz/.2.fq.gz pair was corrupted, then there will be a large number of singleton reads from the file that was successfully copied. You would expect the unique mapping rate of these singleton reads to be only slightly less than the the unique mapping rate for the paired end reads. The difference between the two will be due to the aligner being able to use the partner read to disambiguate the mapping location for the pair end reads, but not the singletons.

TLDR: that behaviour is expected; they're probably correct; redownload the correct data before continuing