Porechop
Porechop copied to clipboard
rrwick
None barcode
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:
head -n 1300 nanpore_run2.fastq > test.fastq
Now when I run it, it will detect the following barcodes and demultiplex/trim based on those:
singularity exec ~/.singularity/porechop.img porechop -i test.fastq -v 1 -t 16 --barcode_threshold 50 -b mux
Trimming adapters from read ends
SQK-NSK007_Y_Top: AATGTACTTCGTTCAGTTACGTATTGCT
SQK-NSK007_Y_Bottom: GCAATACGTAACTGAACGAAGT
1D2_part_2_start: CTTCGTTCAGTTACGTATTGCTGGCGTCTGCTT
1D2_part_2_end: CACCCAAGCAGACGCCAGCAATACGTAACT
BC01_rev: CACAAAGACACCGACAACTTTCTT
BC01: AAGAAAGTTGTCGGTGTCTTTGTG
BC02_rev: ACAGACGACTACAAACGGAATCGA
BC02: TCGATTCCGTTTGTAGTCGTCTGT
BC03_rev: CCTGGTAACTGGGACACAAGACTC
BC03: GAGTCTTGTGTCCCAGTTACCAGG
BC01: AAGAAAGTTGTCGGTGTCTTTGTG
BC01_rev: CACAAAGACACCGACAACTTTCTT
BC02: TCGATTCCGTTTGTAGTCGTCTGT
BC02_rev: ACAGACGACTACAAACGGAATCGA
BC03: GAGTCTTGTGTCCCAGTTACCAGG
BC03_rev: CCTGGTAACTGGGACACAAGACTC
NB01_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAACACAAAGACACCGACAACTTTCTTCAGCACCT
NB01_end: AGGTGCTGAAGAAAGTTGTCGGTGTCTTTGTGTTAACCTTAGCAATACGTAACTGAACGAAGT
NB02_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAAACAGACGACTACAAACGGAATCGACAGCACCT
NB02_end: AGGTGCTGTCGATTCCGTTTGTAGTCGTCTGTTTAACCTTAGCAATACGTAACTGAACGAAGT
NB03_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAACCTGGTAACTGGGACACAAGACTCCAGCACCT
NB03_end: AGGTGCTGGAGTCTTGTGTCCCAGTTACCAGGTTAACCTTAGCAATACGTAACTGAACGAAGT
325 / 325 (100.0%)
299 / 325 reads had adapters trimmed from their start (13,934 bp removed)
205 / 325 reads had adapters trimmed from their end (5,183 bp removed)
Discarding reads containing middle adapters
325 / 325 (100.0%)
47 / 325 reads were discarded based on middle adapters
Saving trimmed reads to barcode-specific files
Barcode Reads Bases File
BC01 41 15,980 mux/BC01.fastq
BC02 78 34,759 mux/BC02.fastq
BC03 47 20,117 mux/BC03.fastq
none 112 50,420 mux/none.fastq
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".
head -n 1400 tcseq_nanpore_run2.fastq > test.fastq
singularity exec ~/.singularity/porechop.img porechop -i test.fastq -v 1 -t 16 --barcode_threshold 50 -b mux
Trimming adapters from read ends
SQK-NSK007_Y_Top: AATGTACTTCGTTCAGTTACGTATTGCT
SQK-NSK007_Y_Bottom: GCAATACGTAACTGAACGAAGT
1D2_part_2_start: CTTCGTTCAGTTACGTATTGCTGGCGTCTGCTT
1D2_part_2_end: CACCCAAGCAGACGCCAGCAATACGTAACT
BC01_rev: CACAAAGACACCGACAACTTTCTT
BC01: AAGAAAGTTGTCGGTGTCTTTGTG
BC02_rev: ACAGACGACTACAAACGGAATCGA
BC02: TCGATTCCGTTTGTAGTCGTCTGT
BC03_rev: CCTGGTAACTGGGACACAAGACTC
BC03: GAGTCTTGTGTCCCAGTTACCAGG
BC01: AAGAAAGTTGTCGGTGTCTTTGTG
BC01_rev: CACAAAGACACCGACAACTTTCTT
BC02: TCGATTCCGTTTGTAGTCGTCTGT
BC02_rev: ACAGACGACTACAAACGGAATCGA
BC03: GAGTCTTGTGTCCCAGTTACCAGG
BC03_rev: CCTGGTAACTGGGACACAAGACTC
NB01_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAACACAAAGACACCGACAACTTTCTTCAGCACCT
NB01_end: AGGTGCTGAAGAAAGTTGTCGGTGTCTTTGTGTTAACCTTAGCAATACGTAACTGAACGAAGT
NB02_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAAACAGACGACTACAAACGGAATCGACAGCACCT
NB02_end: AGGTGCTGTCGATTCCGTTTGTAGTCGTCTGTTTAACCTTAGCAATACGTAACTGAACGAAGT
NB03_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAACCTGGTAACTGGGACACAAGACTCCAGCACCT
NB03_end: AGGTGCTGGAGTCTTGTGTCCCAGTTACCAGGTTAACCTTAGCAATACGTAACTGAACGAAGT
350 / 350 (100.0%)
324 / 350 reads had adapters trimmed from their start (14,999 bp removed)
220 / 350 reads had adapters trimmed from their end (5,627 bp removed)
Discarding reads containing middle adapters
350 / 350 (100.0%)
58 / 350 reads were discarded based on middle adapters
Saving trimmed reads to barcode-specific files
Barcode Reads Bases File
none 292 127,150 mux/none.fastq
How is that possible?
If I compare the -v 3 output for the first read, it is already obvious that there is something off:
6364be98-8dcf-4897-bac5-7a2f9def148a runid=03eec05c36f3e19a293608bac1f8877f948142e7 read=10580 ch=232 start_time=2018-09-14T15:47:19Z
start: ATGTTGTGCCCCGTTCAATTTACGTATTGCTGAGTCTTGTGTCCCAGTTGCAGGGTGACTGGAGTTCAGGCAATGTGCTCTTCCGATCTGACTGGAGTTAGACGTATTAACTCTTCGGTCTGACTGGAGTTCAGACGTGTGCTCTTCCGA...
start alignments:
Barcode 3 (forward), full score=91.666667, partial score=91.666667, read position: 31-54
end: ...AAGAGCGTCGTGTAGAAAGAGTGTAGAGAGTCTTGTGTCCCAGTTACCAGGGTGACTGGAGTTCAGACGTGTGCTTTCCGATCTGACTGGAGTTCAGACGTGTGCTCTTCCGTCTGACTGGAATTCAGACGTGTGCCTTCCCGATCTGGC
end alignments:
Barcode 3 (reverse), full score=100.0, partial score=100.0, read position: 27-51
Barcodes:
start barcodes: BC03 (91.7%), BC01 (23.1%), BC02 (71.4%)
end barcodes: BC03 (26.9%), BC01 (4.2%), BC02 (16.7%)
best start barcode: BC03 (91.7%)
best end barcode: BC03 (26.9%)
final barcode call: BC03
vs
6364be98-8dcf-4897-bac5-7a2f9def148a runid=03eec05c36f3e19a293608bac1f8877f948142e7 read=10580 ch=232 start_time=2018-09-14T15:47:19Z
start: ATGTTGTGCCCCGTTCAATTTACGTATTGCTGAGTCTTGTGTCCCAGTTGCAGGGTGACTGGAGTTCAGGCAATGTGCTCTTCCGATCTGACTGGAGTTAGACGTATTAACTCTTCGGTCTGACTGGAGTTCAGACGTGTGCTCTTCCGA...
start alignments:
Barcode 3 (forward), full score=91.666667, partial score=91.666667, read position: 31-54
end: ...AAGAGCGTCGTGTAGAAAGAGTGTAGAGAGTCTTGTGTCCCAGTTACCAGGGTGACTGGAGTTCAGACGTGTGCTTTCCGATCTGACTGGAGTTCAGACGTGTGCTCTTCCGTCTGACTGGAATTCAGACGTGTGCCTTCCCGATCTGGC
end alignments:
Barcode 3 (reverse), full score=100.0, partial score=100.0, read position: 27-51
Barcodes:
start barcodes:
end barcodes:
best start barcode: none (0.0%)
best end barcode: none (0.0%)
final barcode call: none
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
start: TCATTGTACTTCGTTCGAAGTTACGTATTGCTAAGCGTCATTATCAACGCAGGTACTTTTTTTTTGAGCAAGTATGGTTGTACGGACAAATGGTAGAAAAATGTTACTAATATCCATAGATAAGTTCCTTAAGTCGTAGCAGAGACTGTT...
start alignments:
SQK-NSK007, full score=90.0, partial score=90.0, read position: 2-32
1D^2 part 2, full score=80.555556, partial score=80.555556, read position: 8-42
end: ...TTCCTGCCGACGACTCGCGTCCGCCTCTCGCCTGGAGTGCCCTTCCCGCGGCTTTCCTGCCCGCTGTGTCCCCGCTATAAGAAGAGCTGGGCTCGATTCCTGTCATCCCCAGATCCGGAAGAGTCGTGTAGAGCAATACGTAATGGCACC
end alignments:
SQK-NSK007, full score=62.5, partial score=78.947368, read position: 132-150
10x Chromium Read 1, full score=86.956522, partial score=86.956522, read position: 110-131
Barcode Chromium 133, full score=76.470588, partial score=76.470588, read position: 5-20
Barcode Chromium 1069, full score=100.0, partial score=100.0, read position: 93-109
Barcodes:
start barcodes:
end barcodes:
best start barcode: none (0.0%)
best end barcode: none (0.0%)
final barcode call: none
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: https://github.com/rrwick/Porechop/issues/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: https://github.com/rrwick/Porechop/commit/3fde10ff6a66be2a7579807612b0133414720402 I altered my code to match what was there but noticed that there were other differences as well. I tried to run Porechop anyways and it gave me some error that there were no barcodes detected or something or other. Unfortunately I've been completely swamped with more pressing work but plan to go through the Porechop code and try to piece together this mysterious 0.3.4 beta version once I have some more time. With that said, I encourage anyone reading this who has more experience with coding than me (limited python and some other basics) to go through and try it themself and to then share it with others.
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
https://github.com/rrwick/Porechop/issues/44#issuecomment-362465575
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. https://github.com/rrwick/Porechop/pull/47#issue-166999701 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:
https://github.com/rrwick/Porechop/commit/3fde10ff6a66be2a7579807612b0133414720402
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', start_sequence=('EMP', 'CACATATCAGAGTGCG'), end_sequence=('EMP', 'CGCACTCTGATATGTG')),
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)', start_sequence=('EMP', 'CACATATCAGAGTGCG'), end_sequence=('EMP_rev', 'CGCACTCTGATATGTG')),
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: 3622/8000 were discarded based on middle adapters (this number seems exceptionally high) 1767/8000 were binned to none 2611/8000 were binned to one of my 27 barcodes (the avg of this being 97/bc)
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.
@pengelgau
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: I would definitely increase the middle_threshold. With the number of barcodes I am working with I was getting around 60% of my reads meeting the threshold for at least one if not several. PCR artifacts is a thing but it doesn't make sense that so many barcodes are found within one read and literally splicing it up into tiny fragments. When running porechop with the standard adapters I see few split reads. By increasing the threshold this dramatically reduced. I wonder if there is a way to only use adapters and not barcodes to look for chimeric reads. Anyway I may ignore chimeric read for time being as just focus on getting the binning right.
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.
deepbinner/barcode11.fastq.gz
343,115 reads loaded
Looking for known adapter sets
10,000 / 10,000 (100.0%)
Best
read Best
start read end
Set %ID %ID
SQK-NSK007 100.0 82.6
Rapid 69.4 0.0
SQK-MAP006 77.4 81.8
SQK-MAP006 Short 74.1 76.0
PCR adapters 1 78.3 78.3
PCR tail 1 77.4 77.4
PCR tail 2 73.3 74.2
1D^2 part 1 76.7 75.0
1D^2 part 2 88.2 75.0
Barcode 1 (reverse) 79.2 79.2
Barcode 2 (reverse) 77.8 79.2
Barcode 3 (reverse) 74.1 74.1
Barcode 4 (reverse) 80.8 76.9
Barcode 5 (reverse) 77.8 76.0
Barcode 6 (reverse) 75.0 76.0
Barcode 7 (reverse) 76.9 78.6
Barcode 8 (reverse) 77.8 76.9
Barcode 9 (reverse) 76.9 76.0
Barcode 10 (reverse) 95.8 91.7
Barcode 11 (reverse) 100.0 100.0
Barcode 12 (reverse) 100.0 95.8
Barcode 1 (forward) 76.0 79.2
Barcode 2 (forward) 79.2 76.9
Barcode 3 (forward) 77.8 75.0
Barcode 4 (forward) 76.0 76.0
Barcode 5 (forward) 76.0 77.8
Barcode 6 (forward) 76.0 80.0
Barcode 7 (forward) 77.8 76.9
Barcode 8 (forward) 77.8 79.2
Barcode 9 (forward) 79.2 76.0
Barcode 10 (forward) 80.8 95.8
Barcode 11 (forward) 75.0 100.0
Barcode 12 (forward) 91.7 100.0
Barcode 13 (forward) 76.0 75.0
Barcode 14 (forward) 79.2 75.0
Barcode 15 (forward) 76.0 73.1
Barcode 16 (forward) 75.0 75.0
Barcode 17 (forward) 75.9 79.2
Barcode 18 (forward) 80.0 83.3
Barcode 19 (forward) 76.9 80.0
Barcode 20 (forward) 77.8 79.2
Barcode 21 (forward) 76.0 76.9
Barcode 22 (forward) 76.0 78.6
Barcode 23 (forward) 75.0 77.8
Barcode 24 (forward) 75.0 76.0
Barcode 25 (forward) 76.0 76.9
Barcode 26 (forward) 75.0 79.2
Barcode 27 (forward) 76.0 76.9
Barcode 28 (forward) 80.0 80.8
Barcode 29 (forward) 76.9 76.0
Barcode 30 (forward) 76.0 76.9
Barcode 31 (forward) 79.2 79.2
Barcode 32 (forward) 76.0 80.0
Barcode 33 (forward) 77.8 75.0
Barcode 34 (forward) 79.2 79.2
Barcode 35 (forward) 76.9 75.0
Barcode 36 (forward) 77.8 76.9
Barcode 37 (forward) 79.2 76.0
Barcode 38 (forward) 76.0 76.0
Barcode 39 (forward) 75.0 76.0
Barcode 40 (forward) 76.0 76.0
Barcode 41 (forward) 76.0 73.1
Barcode 42 (forward) 76.0 76.0
Barcode 43 (forward) 75.0 76.0
Barcode 44 (forward) 77.8 76.0
Barcode 45 (forward) 76.0 76.0
Barcode 46 (forward) 79.2 77.8
Barcode 47 (forward) 76.0 76.0
Barcode 48 (forward) 76.0 76.9
Barcode 49 (forward) 79.2 77.8
Barcode 50 (forward) 79.2 76.9
Barcode 51 (forward) 73.1 76.9
Barcode 52 (forward) 76.0 76.0
Barcode 53 (forward) 80.0 79.2
Barcode 54 (forward) 77.8 80.0
Barcode 55 (forward) 80.8 76.0
Barcode 56 (forward) 76.9 77.8
Barcode 57 (forward) 77.8 83.3
Barcode 58 (forward) 76.0 80.0
Barcode 59 (forward) 79.2 80.0
Barcode 60 (forward) 79.2 76.9
Barcode 61 (forward) 75.0 76.0
Barcode 62 (forward) 80.8 84.0
Barcode 63 (forward) 76.9 80.0
Barcode 64 (forward) 75.0 76.0
Barcode 65 (forward) 76.0 76.0
Barcode 66 (forward) 76.0 76.0
Barcode 67 (forward) 76.0 79.2
Barcode 68 (forward) 76.9 80.0
Barcode 69 (forward) 74.1 76.0
Barcode 70 (forward) 76.0 76.0
Barcode 71 (forward) 75.0 76.0
Barcode 72 (forward) 76.0 79.2
Barcode 73 (forward) 76.0 79.2
Barcode 74 (forward) 79.2 80.0
Barcode 75 (forward) 76.0 77.8
Barcode 76 (forward) 76.0 76.9
Barcode 77 (forward) 76.9 76.9
Barcode 78 (forward) 79.2 76.9
Barcode 79 (forward) 79.2 76.9
Barcode 80 (forward) 76.0 76.9
Barcode 81 (forward) 76.0 78.6
Barcode 82 (forward) 76.7 76.9
Barcode 83 (forward) 76.0 77.8
Barcode 84 (forward) 76.0 77.8
Barcode 85 (forward) 75.0 76.0
Barcode 86 (forward) 76.0 76.0
Barcode 87 (forward) 80.0 75.0
Barcode 88 (forward) 75.0 80.8
Barcode 89 (forward) 80.0 80.0
Barcode 90 (forward) 75.0 74.1
Barcode 91 (forward) 75.0 73.1
Barcode 92 (forward) 76.9 76.0
Barcode 93 (forward) 76.0 79.2
Barcode 94 (forward) 79.2 80.0
Barcode 95 (forward) 76.9 79.2
Barcode 96 (forward) 75.0 76.0
Trimming adapters from read ends
SQK-NSK007_Y_Top: AATGTACTTCGTTCAGTTACGTATTGCT
SQK-NSK007_Y_Bottom: GCAATACGTAACTGAACGAAGT
BC10_rev: GAGAGGACAAAGGTTTCAACGCTT
BC10: AAGCGTTGAAACCTTTGTCCTCTC
BC11_rev: TCCATTCCCTCCGATAGATGAAAC
BC11: GTTTCATCTATCGGAGGGAATGGA
BC12_rev: TCCGATTCTGCTTCTTTCTACCTG
BC12: CAGGTAGAAAGAAGCAGAATCGGA
BC10: AAGCGTTGAAACCTTTGTCCTCTC
BC10_rev: GAGAGGACAAAGGTTTCAACGCTT
BC11: GTTTCATCTATCGGAGGGAATGGA
BC11_rev: TCCATTCCCTCCGATAGATGAAAC
BC12: CAGGTAGAAAGAAGCAGAATCGGA
BC12_rev: TCCGATTCTGCTTCTTTCTACCTG
NB10_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAAGAGAGGACAAAGGTTTCAACGCTTCAGCACCT
NB10_end: AGGTGCTGAAGCGTTGAAACCTTTGTCCTCTCTTAACCTTAGCAATACGTAACTGAACGAAGT
NB11_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAATCCATTCCCTCCGATAGATGAAACCAGCACCT
NB11_end: AGGTGCTGGTTTCATCTATCGGAGGGAATGGATTAACCTTAGCAATACGTAACTGAACGAAGT
NB12_start: AATGTACTTCGTTCAGTTACGTATTGCTAAGGTTAATCCGATTCTGCTTCTTTCTACCTGCAGCACCT
NB12_end: AGGTGCTGCAGGTAGAAAGAAGCAGAATCGGATTAACCTTAGCAATACGTAACTGAACGAAGT
343,115 / 343,115 (100.0%)
320,913 / 343,115 reads had adapters trimmed from their start (23,153,172 bp removed)
153,181 / 343,115 reads had adapters trimmed from their end (6,322,450 bp removed)
Discarding reads containing middle adapters
343,115 / 343,115 (100.0%)
11,382 / 343,115 reads were discarded based on middle adapters
Saving trimmed reads to barcode-specific files
pigz found - using it to compress instead of gzip
Barcode Reads Bases File
none 330,962 230,663,797 porechop/barcode11/none.fastq.gz
This sample should contain almost only BC11 reads. It clearly detects the correct barcodes (BC10, BC11, BC12 - reverse) but does not demultiplex. It works for the two other barcodes BC10 and BC12, but not for this one.
Seems broken on a basic level - never had this problem before.
Fixed it by installing the 0.2.4-beta from development branch: e.g. run: pip install git+https://github.com/rrwick/Porechop.git@development
See here: https://github.com/rrwick/Porechop/issues/44#issuecomment-362465575
Guess this should be merged into master branch in pushed to PyPI and bioconda
Dear all, I also re-installed porechop 0.2.4-beta following #44 (comment) but no use. Finally, I solved the problem by referring to https://github.com/Psy-Fer/Porechop, and edit alt_adapters.py: ./porechop-runner.py -i where/is/the/fastq/*.fastq -b /test/folder -AP ./alt_adapters.py -AN adapters -t 20
