minions cannot keep up demultiplex in realtime

[DABAKER165]

In all of our experiments Minions cannot keep up with live-basecalling and demultiplexing in realtime. When this happens, the software stops live basecalling and demultiplexing and sends all the reads to fast5_skip folder. Every one of our runs has sent >99% of the reads are sent to fast5_skip.

When we turn off demultiplexing, the live-basecalling can keep up and the reads are sent to fastq_pass or fastq_fail, though not demultiplexed, we at least get a lot of the computational processing out of the way.

With any sequencer, there is a possibility that software does not keep up and the reads are sent to fast5_skip.

This workflow will not address that issue as it assumes an error free run that potentially will miss considering reads.

This means we either have to build a pipeline to pre-process the reads (basecall and/or demultiplex). We would need the option to run a demultiplexing step for this pipeline so we can continue to use the pipeline for our Minions.

Additionally, it would be nice to see an example of software and arguments needed to fulfill the following criteria (guppy_barcoder?): "The Midnight protocol uses a rapid barcoding kit; it is therefore important to note that the demultiplexing step must not require barcodes at both ends of the sequence. It is also not necessary to filter against mid-strand barcodes."

[cjw85]

Hi @DABAKER165,

You are correct that this workflow does not currently handle a demultiplexing step. This is something we are looking to add in the future.