I haven’t confirmed that this will work (so beware!), but I have been meaning to try setting decontaminate_pairs to lenient to see if that will bypass this issue.
1 Like
Hi @levlitichev, I just tried that with my data and got a bowtie2 error: “fewer reads in file specified with -2 than in file specified with -1”. It’s been puzzling me because I confirmed that the number of reads were the same in each pair in the raw files and after going through trimmomatic, so now I’m trying to see if something went wrong in TRF (prior step before bowtie2).
In any case, wasn’t very helpful for solving the original issue.
I think the issue here is caused by bowtie2 not recognising the read pairs due to changes in their header line formatting introduced by Kneaddata at the begining of the wrapper.
I can align my reads to the same bowtie2 index used by Kneaddata prior to processing them with kneaddata, but if I try to use the reads that results from the trf step, these do not get sorted into the paired unaligned output files.
My current work around is aligning the reads myself against the bowtie2 indices prior to using kneaddata to run trimmomatic and trf. If the modified read headers cause an issue downstream in kraken2 I might just have to drop Kneaddata or introduce a step to patch the modified header lines.
Current working hypothesis at least.
Hello,
I am dealing with the same problem: all my paired-end data are in my unpaired output.
I changed the name of my id (as you can see in the picture below) but it didn’t resolve the problem…
Thank you in advance for your help
Hi thank you for you answer @levlitichev !
Now I am not sure about the problem, because the name of the reads seams to
be changing…
Because if I look on the .command.log file, I see this line
“Reformatting file sequence identifiers…”
Does that mean that my results are correct? Cause if the name are changed,
maybe the void in my “paired” file are normal?
I think the reformatting is normal. It’s how KneadData makes sure that it can match up the forward and reverse reads. The problem (with v0.12.0) is that bowtie2 still can’t figure out how to match up the forward and reverse reads, so it returns zero for paired reads (“INFO: READ COUNT: final pair1” and “pair2” above). With v0.10.0, this problem appears to be fixed (for me). This is my understanding at least.
2 Likes