Paired FASTQ files do not show equal amount of reads

Question

[K.Nijbroek]

Hi,

I've got a data sample consisting of two mate-paired FASTQ files. I've applied paired-end Trimmomatic on both these FASTQ files and retrieved a forward_accepted.fq and a reverse_accepted.fq. Now I applied Bowtie2 to align both FASTQ files in forward-reverse order, and it seems like there seems to be inconsistency in the amount of reads of the forward_accepted.fq and the reverse_accepted.fq.

Is there some easy way to fix this, such as a picard/gatk/samtools command that is able to delete the incorrect read pairs, or continue with the correct read pairs? Best solution for me would be input of 2 incorrect FASTQ files, and output of 2 correct FASTQ files.

[Pierre Lindenbaum]

did you check gunzip -c your.fastq.gz | wc -l for all your files?

[K.Nijbroek]

Both FASTQ files have the exact same amount of lines. Seems like Bowtie2 is doing something odd then?

[Pierre Lindenbaum]

Is there any empty fastq? length(seq)==0?

[K.Nijbroek]

Bowtie2: 'Error, fewer reads in file specified with -2 than in file specified with -1'. Both FASTQ files have exact same amount of lines and seqs are not 0 (I require minlen 50). I can't figure out why all other samples prepared with the same processing steps do work, while this one won't...

[Devon Ryan]

I wonder if one of the lines got misformatted such that it thinks the file ends earlier. Perhaps try using -u to see how far it can get before terminating.

[K.Nijbroek]

I will do that. I've also prepared a Bowtie2 command on the raw .FASTQ files (before Trimming), and that works fine. It seems like trimming is doing something wrong... although the number of lines in trimmed files are the same...

[K.Nijbroek]

I did an another additional run for the trimmed FASTQ files and somehow everything went well this time. Now I'm completely flabbergasted....

Answer 1

[Devon Ryan]

It's likely that you trimmed the files separately, rather than as a pair. Trimmomatic can handle the files as a pair, so just have it do so.

Note that there are also threads on resyncing the fastq files if you absolutely insist on going that route. How To Sort Two Mate Pair (Fastq) Files So That The Order Of The Identifiers Is The Same? and Combining The Paired Reads From Illumina Run are two go-to references for this.

[K.Nijbroek]

I didn't do separate Trimming, I used Paired-End. That's why I find it so strange that in this case the FASTQ files show inconsistency, because for other samples it does work.

[Devon Ryan]

That's quite odd then. If you can make a reproducible example of that then it'd be helpful if you submitted a bug report to the trimmomatic authors. In any case, the two threads that I linked to provide some ways to recover from this.