High Read Loss During Detect

[Sgreenfield9]

Hello,

We've been encountering an unexpectedly high read loss (approximately 40–60%) when running the detect step in DNAscent 4.0.3, and we’re trying to determine the cause. This dropout rate is significantly higher than anticipated, and it's impacting our ability to assess BrdU incorporation with confidence. A significant number of reads are filtered out, making it difficult to distinguish true from false positive BrdU calls due to limited retained data.

We've ruled out several possible issues:

Read length and mapping quality: We relaxed thresholds for both but observed no improvement.

Basecalling: We've tested both fast and sup models using Dorado with version 0.8.3.

Data quality: Libraries were prepared by pulsing yeast (expressing hENT1 and hsvTK) with 160 µM BrdU for 5 minutes. DNA was extracted post-sodium azide treatment. Basecalling, demultiplexing, and alignment were all done with Dorado, and we then ran index and detect with DNAscent 4.0.3.

BrdU incorporation: Confirmed effective by slot blotting with anti-BrdU antibodies.

Cross-validation: We tested a BrdU-negative dataset from a collaborator (prepared using the same kit and flowcell version) and observed a similarly high dropout rate during detect.

Read ID consistency: Only 184 reads in the BAM file were missing from the index.dnascent file, so this discrepancy doesn't explain the large read loss.

Given this, we’re wondering if there are other internal filtering steps within detect that could be contributing to this issue. Is there any publicly available test dataset we could use to verify that we’re running the pipeline correctly?

Thank you for your time and support,
Sam

[MBoemo]

That is quite surprising and unexpected. When you say "read loss" do you mean you're seeing a failure rate of 40-60% on DNAscent detect? (If not, what's the failure rate?) Or do you mean that you're getting 40-60% of the reads from DNAscent detect that ONT tells you that you should have?

N.B., I'm away at the moment so might be slow - I'll be back in Cambridge as of 25 April.

[Sgreenfield9]

To clarify I'm having failure to retain reads (i.e., dropped or unprocessed by detect). I'm getting 40-60% of the reads out of DNAscent detect that ONT tells me I should have. I'm determining this by looking at the number of reads in my original fastq files compared to the number that appear in my detect output.

Thank you for the quick reply and the heads up!

[Sgreenfield9]

Update: I've been sandboxing the code with subsets of reads and it looks like it's the eventAlignment function called within detect.cpp that is causing my reads to fail.

Will next try and dig into this to see why this vector is 0 for many of my reads.

[MBoemo]

Back in Cambridge now - which Dorado basecalling model are you using?

[Sgreenfield9]

I'm using Dorado v0.8.3. I tried both the dna_r10.4.1_e8.2_400bps sup and fast basecallers with the same results.

I've just finished troubleshooting by doing a second pilot run and it turns out it may have just been a bad run? For my new run I have only ~5% failed by detect. I'm not sure what the difference between the runs are... library preps were the same and I even used the same kit and flow cell.

[MBoemo]

Interesting - I would find a bad run a little surprising, but it might be possible. Hard to say but maybe something to keep an eye on.

[chrisdrichardson]

I'm having the same issue as the original poster: high read loss when I run DNAscent. I mapped reads with dorado 1.0.1 in super accurate mode (dna_r10.4.1_e8.2_400bps_sup@v5.2.0). The resulting bam files were processed using DNAscent 4.0.3 detect.

To try to troubleshoot this, I made a new bam file with the reads that failed DNAscent the first time. There are roughly 2.9 million primary mapped reads in this file, average length of 326, average quality 40.5. I tried rerunning this bam through DNAscent with relaxed quality and length parameters and every read from this file fails.

We will repeat library prep and sequencing to address the short fragment size, but I'm wondering if there is anything we can do to get a glimpse at this data. Are there other parameters that we can relax? Alternatively, is there something other than length or quality that causes reads to fail? I've included an example of a 935nt read that fails DNAscent below.

6f590a24-cb72-4829-8639-ce08ab2ca282 16 chr1 181689 60 2S120M2D808M1S * 0 0 [935nt] [935Qvalues] qs:f:22.0248 du:f:2.2904 ns:i:11452 ts:i:550 mx:i:2 ch:i:418 st:Z:2025-06-04T21:38:31.358+00:00
rn:i:1550 fn:Z:FBC66896_ba8f5064_c4c1ea76_1.pod5 sm:f:93.6924 sd:f:23.5067 sv:Z:pa dx:i:0 RG:Z:ba8f5064-1d0b-4769-8f97-1b394e96db97_dna_r10.4.1_e8.2_400bps_sup@v5.2.0 NM:i:9 ms:i:1439 AS:i:1806 nn
:i:0 de:f:0.00861141 tp:A:P cm:i:68 s1:i:812 s2:i:768 MD:Z:56C63^CT99T122A1A59T286C58T177 rl:i:0

[MBoemo]

Have you tried the 5.0 fast model?

[chrisdrichardson]

Thank you for the suggestion. I tried this and the results are more or less the same - most reads fail DNAscent. It is interesting that the quality scores are much lower with the 5.0 fast model.

dorado output
Reads mapped: 2536389
Average length: 533
Average quality: 18.8

DNAscent output (quality standards lowered to length=100 and quality=5)
Reads mapped: 485265
Average length: 2032
Average quality: 20

When comparing reads that pass versus reads that fail, the number one determinant is length >1kb (as DNAscent states). If you have any additional suggestions for things to try, we will give it a go.

[MBoemo]

It looks like the average read length is very low - is that expected?

DNAscent does a series of normalisations that work better when it can see more bases, hence the minimum read length threshold. My guess would be that's the reason they're failing.