All reads ending up in none bin when demultiplexing #44
Comments
|
I think you've uncovered an interesting bug here! The problem stems from the fact that Porechop tries to determine whether you are using forward or reverse barcodes (different kits add the barcodes onto different ends of the reads). After Porechop determines the barcode orientation, it ignores barcodes in the other direction when demultiplexing. In your case, you have a tie for both orientations: barcodes 1 and 2 hit got 100% for both the forward and reverse directions. This made Porechop fail to recognise either. Also, I'm confused about your results. Specifically, I'm wondering why you ended up with both forward and reverse barcodes on read ends. I'm assuming the correct orientation is forward barcodes, but that's weird too. I thought only the rapid and PCR kits used the forward barcodes, but you're not hitting either rapid or PCR adapters. In fact, you didn't hit any other adapters, besides the barcodes! What kit did you use? Assuming that 'forward' is the correct orientation for your read set, I've pushed a change up to Porechop's development branch that will hopefully fix it for you. Install from the development branch like this: Check you've got the right one with Ryan |
|
Hi Ryan, The change seems to solved the issue, the vast majority of the reads are now assigned to the barcodes. Slightly less than the Albacore demultiplexing, but close enough. The similarity between barcodes did cross my mind, but I didn't think it would be that much of an issue for the algorithm.
The lack of recognizable adapter could possible be caused by the kit used, which was not included in the Albacore database either. The kit used was the SQK-RAB204 rapid 16s amplicon kit, which I think is fairly new. Cheers, |
|
Okay, thanks. If there aren't data privacy issues, is there any chance you could share some of those reads? It might help me to get the new kit adapters into Porechop. I could share a Dropbox directory with you. But no worries if this isn't possible. Ryan |
|
Unfortunately as usual there are some privacy issues with these samples. I've made sure that during the next run, somewhere this week, one of our controls will be run as well. The data from this sample I can freely send, so I'll update you once it's been sequenced. Joost |
|
Do you still need some reads to help with this? |
|
I'm having the same problem with a multiplexed barcoded run on the GridION. Porechop recognizes the adapters and barcodes but doesn't demultiplex them. When I followed the instructions from Feb 1, I only get "0.2.3". |
Hello,
We're currently testing nanopore runs from our GridION. However, the live basecalling software guppy does not seem to support demultiplexing at the moment. As such I wanted to give Porechop a go on this data to compare to Albacore basecalling and demultiplexing.
However, I'm running into the problem that Porechop will recognize the correct barcodes at good identity levels, but keeps binning all reads into the none bin, no matter how lenient I set the barcode recognition. Do you have any idea what might be causing this behaviour? This occurs on both the guppy called fastq files and the albacore fastq files.
Thanks in forward!
Joost
Example commands:
porechop -i total.fastq -b Porechop_Test/porechop -i total.fastq -b Porechop_Test/ --barcode_threshold 60 --barcode_diff 1 --threads 20Log:
The text was updated successfully, but these errors were encountered: