Dorado creates new reads?

[mbhall88]

Issue Report

Please describe the issue:

I extracted the read IDs from a fastq that comes from a sup dorado basecalling run (v0.5.0). I then passed those read ids to pod5 subset and pointed pod5 at the pod5s I basecalled and there are read ids from the fastq that do not exist in the pod5s. And indeed, when I inspect the pod5 file a particular fastq read comes from (using the fn:Z:<fname> tag) that read id doesn't actually exist in there...Is this a known thing?

In the runs I am working with there are 2494275/34092978 (7.3%) fastq reads with no associated pod5 read.

Run environment:

• Dorado version: 0.5.0
• Dorado command: basecaller
• Operating system:
• Hardware (CPUs, Memory, GPUs):
• Source data type (e.g., pod5 or fast5 - please note we always recommend converting to pod5 for optimal basecalling performance):
• Source data location (on device or networked drive - NFS, etc.):
• Details about data (flow cell, kit, read lengths, number of reads, total dataset size in MB/GB/TB):
• Dataset to reproduce, if applicable (small subset of data to share as a pod5 to reproduce the issue):

[tijyojwad]

Yes this can happen because of read splitting. The original reads from pod5 are split into subread which have different read ids. However each of those records will have a pi:Z tag which point to the original read id they came from.

[esteinig]

Could you explain what will cause a Pod5 read to be split?

[tijyojwad]

some detail here - https://github.com/nanoporetech/dorado/blob/release-v0.5.3/documentation/SAM.md#split-read-tags