Open cnluzon opened 7 months ago
Hello,
Thank you for your detailed reporting on this issue and providing sample reads that I could use to recreate it. I have pushed a change to bug_fixes
branch that should resolve this issue. Let me know if your thoughts.
Update -- I found an issue with the code that I am looking into. I apologise for the inconvenience.
No problem! right now I have it pinned to the previous version. Thanks for your rapid response!
This latest iteration should work. Here is the output I get when trying to align the test data against some generic index. Thank you for your patience.
4 reads; of these:
3 (75.00%) were paired; of these:
3 (100.00%) aligned concordantly 0 times
0 (0.00%) aligned concordantly exactly 1 time
0 (0.00%) aligned concordantly >1 times
----
3 pairs aligned concordantly 0 times; of these:
0 (0.00%) aligned discordantly 1 time
----
3 pairs aligned 0 times concordantly or discordantly; of these:
6 mates make up the pairs; of these:
6 (100.00%) aligned 0 times
0 (0.00%) aligned exactly 1 time
0 (0.00%) aligned >1 times
1 (25.00%) were unpaired; of these:
1 (100.00%) aligned 0 times
0 (0.00%) aligned exactly 1 time
0 (0.00%) aligned >1 times
0.00% overall alignment rate
Hi! I have an issue running
bowtie2
version 2.5.2 that I did not have with previous 2.5.1 version.bowtie2 --version
output:bowtie2 call that returns the error:
The error:
I narrowed down the issue to the smallest FASTQ that would give me the error and I realise that what is triggering the event is an empty sequence read on R2:
I understand this comes from the previous trimming step, but before (bowtie2 2.5.1), the corresponding read on R1 would be mapped. However now it is probably understood as an empty line and bowtie2 thinks that I have different number of reads. I cannot just remove those empty reads on the R2 file because then I would need to remove heir mate in R1 too, so I think this case should somehow be handled? I have not been able to find information on whether FASTQ files allow for such structure, but on the previous 2.5.1 version this would be correctly handled and the read would be outputted as:
in the alignment, with a correct
YT:Z:UU
for a read that was not paired.The verbose output:
The test files:
test_reads.zip