We recently encountered a small bug within the fqfilter script.
For read-IDs containing multiple whitespaces, only the last part (after the last whitespace) was removed due to greedy pattern matching.
Subsequently, read-IDs within the *.unmapped.bam can still contain whitespaces, which causes problems when mapping with STAR.
Adapting the pattern to just match the first non-whitespace character-set within the read-ID fixes this Problem.
Cheers,
Daniel
P.S.: A short example:
Some demultiplexing tools keep the index-combinations within the read-header. This will trigger the bug.
For this read-ID within the fastq file
@VL00118:284:AACMFY5M5:1:1101:33986:1000 1:N:0:0 ACTGAGCG:CGTGTGAT
we would get this read-ID within the unmapped bam
@VL00118:284:AACMFY5M5:1:1101:33986:1000 1:N:0:0
STAR does not throw any error but will fail to get the correct read sequences from the bam, resulting in all reads consisting of only one 'N' within any bam files produced downstream.
Hi there,
hope everything is going well in sweden! :)
We recently encountered a small bug within the fqfilter script. For read-IDs containing multiple whitespaces, only the last part (after the last whitespace) was removed due to greedy pattern matching. Subsequently, read-IDs within the *.unmapped.bam can still contain whitespaces, which causes problems when mapping with STAR. Adapting the pattern to just match the first non-whitespace character-set within the read-ID fixes this Problem.
Cheers,
Daniel
P.S.: A short example: Some demultiplexing tools keep the index-combinations within the read-header. This will trigger the bug. For this read-ID within the fastq file @VL00118:284:AACMFY5M5:1:1101:33986:1000 1:N:0:0 ACTGAGCG:CGTGTGAT we would get this read-ID within the unmapped bam @VL00118:284:AACMFY5M5:1:1101:33986:1000 1:N:0:0
STAR does not throw any error but will fail to get the correct read sequences from the bam, resulting in all reads consisting of only one 'N' within any bam files produced downstream.