-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
None barcode #75
Comments
If I compare the -v 3 output for the first read, it is already obvious that there is something off:
vs
|
hey @t-neumann Did you managed to get this working. I am also having similar issue but custom barcodes. When it does a scan at beginning finds several barcodes but then all reads get dumped to none. Downsampling my reads does not do anything. |
235d60c2-7ef1-478b-a0bc-4bf3e7034d83 runid=9b171acd18baff6564a2a0e0c162878b3a497f62 read=100 ch=12 start_time=2018-07-28T10:05:46Z Here I can see that it perfectly aligns first the ONT adapter from 150-132 then read 1 of illumina-specific PCR step 131-110, and finally the single cell barcode with a 100% perfect match to BC 1069 but it is binned to none? There is another barcode identified but this is a very large difference between the two. |
@callumparr I'm experiencing the exact issue with custom barcodes. When I look at the verbose output I see my barcodes within it and they are different enough from the next most similar but still all of my reads go to none. Someone had a similar issue around Feb 2018 and Ryan responded to it and made an updated version or Porechop with it being 0.3.4 beta. You can read the thread here: #44 When I try to download this new version I can't find it. In fact, I can't find it anywhere. I even emailed Ryan two weeks ago and haven't heard back. I really hope he hasn't abandoned Porechop. It'd really put myself, probably you, and I'm sure many others in a bind. I'd hope ONT would get involved and try to make their own program for custom barcodes but I suppose doing so would devalue their barcoding kits. Regardless I don't think all hope is lost. Because of the way github saves commits I went hunting and saw that on the development thread he made edits on the same day as his response to that person's issue, seemingly with the fix. I went through my own code for Porechop and sure enough the code in the development thread were different from mine. Here's an example of one of the commits of that day: 3fde10f |
Unfortunately I haven't found any solution yet. I tried to look into his new thing based on fast5 files deepbinner (https://github.com/rrwick/Deepbinner) but the description says it was only trained for rapid barcoding kits, so that's no help for my native barcoding kit or your custom barcodes. I really hope porechop development is not dead. |
@pengelgau So I think I may have got it working but the I only tested on a 25 reads so far; By the way I think the commit and beta is actually 2.4. Did you try this recommended cmd The standard branch with git clone cmd is 2.3. Where did you see 3.4 beta in that thread? I am not sure if this is a general problem, but if you are providing custom barcodes either directly in the adapter.py file or using the -f option linking to a csv file containing your barcodes, you need to explicitly put (forward) following the barcode name, e.g. Barcode 1 (forward).... Barcode n (forward). Maybe this is because the logic of pore chop handles current ONT barcodes where some run in reverse complement at the 5' molecule and the more intuitive PCR barcodes run with the template at the 5' of the molecule. An additional thing I did that I didn't bother with was to comment out the existing barcode section in the adapter.py file using """......""". I doubt this made a difference, as there weren't previous conflicts with my custom barcodes before. I had already created a copy of the porechop.py file from this pull , so I can use the -f option instead of having to include 1000 barcodes in the adapter.py file. #47 (comment) here you can see there is an import for a csv file and then other commits to go along with. I think this is the commit you were talking about: Have you tried just copying the entire revised porechop script from this when you click view and overwriting the existing porechop script in your porechop directory? @t-neumann I am unsure if this will help you as you are using the current barcodes already listed in the Porechop right? |
@callumparr You are right. I meant to be saying 2.4 beta. Sorry for the confusion. I did try those cmds from #44 and only got 2.3. I do think you are onto something with regards to having to have "(forward)" for the barcodes. I inserted my barcodes directly into the adapters.py file and didn't include "(forward)" like how all the other present barcodes have them. Here's an example of what mine used to look like: Adapter('Barcode EMP', With this input Porechop was having the same issues that you have listed earlier. This morning I went through and added "(forward)" and "_rev" so that now it looks like this: Adapter('Barcode EMP (forward)', And now after running it on 8000 reads I'm getting recognition and it is binning them to all ~20 of my barcodes. However the numbers are low and makes me wonder if I need the rev seq and if having it there could possibly be causing problems. I added the barcodes to my amplicons by adding the seq to my forward primer. The adapters were then added with an ONT kit. I'm not fully familiar with the details of how it is actually sequenced but I would think that it would basecall both forward and reverse directions of the amplicons depending on what direction they enter the pore (again, not super familiar with details, this may be a bad assumption) and thus I would think that I should add a rev version of my barcode. Does that make sense? Here are the numbers I am getting for one of my ~250 8000-read files: I think I'll next tweak the requirements on middle adapters. Maybe one of those already present barcodes in adapters.py is naturally within my sequence and is causing so many to be discarded for middle adapters. Maybe I will try using my original suggestions of recreating 2.4 from the commits but if I can get it working with just 2.3 I probably won't bother. Anyways I will continue to work on this later in the week. Great insight on including "(forward)". That really should be better listed in that earlier part explaining how to insert your own barcodes. I will update if I can improve my binnings. |
@callumparr Yes they are already listed, so that's not something that would help me. |
Yes exactly, in the case of ONT PCR barcodes, the top part of the adaptor can be in line wit the barcode from either strand. But in my case the barcode should really only been found in the forward sense, as I have 5' capture with oligo containing the barcode. I would double check the reads carefully because in my case it was calling barcode (reverse sense) in orientation with the polyA which clearly biochemically doesn't make sense but it had a higher identify then any other barcode in the forward sense. I think is down to us using porechop for something it was not designed for and would require to rewrite the logic to indicate the barcodes need to be on the top strand in forward sense or bottom strand in reverse sense only, like other strand aware library preps. My recommendation is to get @rrwick 2.4 beta commit working as I think he changed up the logic for this. For middle adapter detection: |
Just chiming in to say I have the same problem, even for standard native barcodes. These reads were pre-binned (to BC10, BC11, BC12) with deepbinner, and for adapter chopping I ran porechop.
This sample should contain almost only BC11 reads. Seems broken on a basic level - never had this problem before. |
Fixed it by installing the 0.2.4-beta from development branch: See here: Guess this should be merged into master branch in pushed to PyPI and bioconda |
Dear all, |
Hi,
I have a very puzzling demultiplexing problem which I have no idea why it occurs.
I have a couple of nanopore reads with bc1, bc2, bc3 but when I run the entire set, all go to the "None" barcode section. So I went down and downsampled the reads:
Now when I run it, it will detect the following barcodes and demultiplex/trim based on those:
Not a great yield, but still stuff is happening. Now I add 25 reads more - it detects the same set of barcodes but all of a sudden, all are labelled as "None".
How is that possible?
The text was updated successfully, but these errors were encountered: