Was just checking if we could add the adapter search directly, then "slice" out all sub-reads so splitting does still look at the barcodes. And thanks for the discussions, nice to get ideas from what else to improve :)

Indeed does happen, but more often they are duplex reads that are not detected as such by Dorado. Then the sequences on either side of the mid strand adapter are reverse complement (example pic)

With Flye? Aah in the preprint we actually used Flye with Dorado trimmed reads 😅. You can see a list of "contaminated" assemblies here: zenodo.org/records/1739..., still quite a few, and this is very strict filtering. In reality there will be more

Yeah Porechop is probably "necessary" when using Dorado, though it shouldn't be. "Appreciable" heavily depends on the application. For assembly a few reads wrong is not always an issue, but for diagnostics a few reads wrong can be a big issue. Of course one should also check scores then, etc.

Hey Misha, on a 10K read sample around 60% is the expected dual-end (top), but often a single-end is enough to assign already. That puts it at around 90% (top 3 in image). Double barcode ligations do happen (bottom) but not sure about the exact stats of bleeding because of that.

To add, you can then add the desired pattern to barbell filter where you put “cut” marks (<<, >>) such that only the long reads is kept and the short contam is cut off

Agree, Barbell will just give a "complex" pattern for those reads which are not added to the output by default. Though, if the reads are very long, and contain little contamination (i.e. long read + short concat read at the end) it might still be worth it including it for assembly

Yeah most of NCBI is down, or outdated at the moment. We will upload them to Zenodo

Hey Kevin, that comes down to the difference between demultiplexing correct and removing contamination. If you had a read with NB01-NB02--read--. Dorado will demux to NB01, and you can remove NB02 contamination using Porechop, but that does mean your read was still demultiplexed incorrect initially

See the thread for a quick summary! bsky.app/profile/rick...

In the pre-print we also discuss a specific tagmentation pattern causing partial loss of the second barcode, a custom barcode scoring scheme, and more: www.biorxiv.org/content/10.1...

In Barbell we solve this by first annotating all the reads, and then detecting all patterns, which looks like this:

Why is this a problem? Remaining adapters/barcodes not only contaminated assemblies but also created "artificial" links in taxonomic annotation, to Enterobacteriaceae, and to contaminated assemblies in NCBI.

Many tools, including the widely used Dorado, almost always only detected the *first* occurrence, leaving the rest untrimmed. In the figure black lines indicate matches to adapters + barcodes in trimmed reads.

For rapid barcoding only ~83% of the reads contain the expected single barcode on the left. The rest? Barcodes on both sides (6.1%), two barcodes on the left side (3.5%), and so on.

😂