Discrepancies between actual reads and polyA tail estimation

[ChristopherAdelmann]

Issue Report

Please describe the issue:

While conducting basecalling on direct RNA samples, I've noticed a discrepancy between the number of base-called bases and the estimated length of polyA tails at the 3' end of the reads. Particularly with shorter reads, it's common to find that the total number of bases in a read is less than the estimated polyA length. This discrepancy might stem from two possible reasons:

A. The polyA estimation might occur prior to adapter trimming, resulting in some A bases being trimmed off and thus shorter reads? B. The number of bases called may not directly correlate with the theoretical polyA length bases?

Either way, including the region of the read corresponding to the polyA tail in the SAM file would be immensely helpful in resolving this issue.

Steps to reproduce the issue:

Basecall short direct RNA reads with polyA tail estimation enabled.

Run environment:

• Dorado version: 0.5.3
• Dorado command: dorado basecaller --min-qscore 5 --emit-sam --emit-moves --estimate-poly-a -k 12 rna002_70bps_hac@v3 pod5_pass
• Operating system: Windows 11
• Hardware (CPUs, Memory, GPUs): AMD Ryzen 9 7900X, 64 GB DDR5 RAM, NVIDIA GeForce RTX 4090
• Source data type (e.g., pod5 or fast5 - please note we always recommend converting to pod5 for optimal basecalling performance): pod5
• Source data location (on device or networked drive - NFS, etc.): on device
• Details about data (flow cell, kit, read lengths, number of reads, total dataset size in MB/GB/TB): flow cell FLO-PRO002, kit SQK-RNA002, number of reads ~800 k
• Dataset to reproduce, if applicable (small subset of data to share as a pod5 to reproduce the issue): Example ReadID: 7e09c57e-4325-4d4b-93e1-c53c598abee6 merged_passed_trimmed_polyA_subset.sam.txt

[tijyojwad]

Hi @ChristopherAdelmann

Yes this discrepancy is currently expected, especially if the tail length is long. This is because the basecaller currently has difficulty calling long homopolymers. However the tail estimation uses a different algorithm that's tuned for determining polyA lengths specifically.

We've had a couple of other people request adding the estimated polyA sequence into the read as well. We'll discuss internally and look into adding this in a subsequent release.