How should I use dorado basecaller to calculate translocation time? Can I change models' config files?

Question

I am trying to use dorado basecaller to process ONT data. I need to make the move table and I am doing it with --emit-move.

dorado basecaller [email protected]/ /pod5_files/ --recursive --emit-moves --modified-bases 5mCG_5hmCG -v > /bams/mod_stride1.bam

The main purpose of the move table for me is to calculate the number of ONT device measurements before basecaller emits one base (calculate translocation time per base). But the stride value in config.toml file is fixed to 5 (stride=5). I need to calculate the instantaneous translocation time per base (in seconds), because I am looking to find a measure similar to IPD values in PacBio, when we can get the time for sequencing each base.

I was wondering to change the stride value in config.toml file in the model folder, from stride=5 to stride=1, to directly infer the number of measurements without using Tombo for correcting and re-squiggling.

Unfortunately, even though this command works perfectly fine when the stride=5, when I set stride=1 it always gives me the following error: "CUDA out of memory", even when I triple the size of RAM for the job.

My questions are:

1. Does setting stride=1 make sense for this purpose? Or do I have to do something else? (I know we have some K-mer models too)
2. Is this even possible to change the stride value on config.toml file?
3. How should I figure out how much RAM I need for the job?

Answer 1

In pod5 files the number of samples prior to the adapter/sequence should be encoded in the metadata, and can be looked at using ONT's pod5 inspect tool:

$ pod5 inspect reads pod5_file.pod5

read_id,channel,well,pore_type,read_number,start_sample,end_reason,median_before,calibration_offset,calibration_scale,sample_count,byte_count,signal_compression_ratio
00445e58-3c58-4050-bacf-3411bb716cc3,908,1,not_set,100776,374223800,signal_positive,205.3,-240.0,0.1,65582,58623,0.447
00520473-4d3d-486b-86b5-f031c59f6591,220,1,not_set,7936,16135986,signal_positive,192.0,-233.0,0.1,167769,146495,0.437
...

The average translocation speed can be worked out by comparing the sample_count to the number of called bases.

More details here.

Unfortunately, due to the way the basecaller models work, I don't think there's any easy way to create a 1-sample lookup table for precise instantaneous translocation calculations.

If it is just an out of memory error, then it should work (but very slowly) if you set the basecaller batch size to 1 (i.e. -b 1). If even that doesn't work, something else is going on and it's unlikely to be a memory problem.