Ryan Wick
@rrwick.bsky.social
1.1K followers 120 following 78 posts
Bioinformatician at the Centre for Pathogen Genomics at the University of Melbourne
Posts Media Videos Starter Packs
rrwick.bsky.social
And since both metaMDBG and Myloasm had new versions after the paper was accepted, here's a blog post with an updated benchmark:
rrwick.github.io/2025/09/23/a...
(3/3)
rrwick.bsky.social
Here's the ultra-short version:
If you want the best possible long-read bacterial genome assemblies, Autocycler is the tool for you! It is computationally intensive (due to the need to generate many alternative input assemblies) but consistently more accurate than other methods.
(2/3)
rrwick.bsky.social
One caveat though: my experience is with isolates that (usually) have a single 'true' sequence to aim for. In a metagenome with natural variation (i.e. a mixture of multiple 'true' sequences), I'm not sure how Dorado/Medaka would behave...
rrwick.bsky.social
I have limited experience with long-read metagenome assembly, so I don't have any special insight here. But I like the examples shown @floriantrigodet.bsky.social's preprint - it shows how sometimes one strange read (e.g. a chimera) can throw off the assembly.
rrwick.bsky.social
No, the assemblies are not Dorado/Medaka polished. I predict doing so would significantly reduce error rates, especially for the higher-error assemblies - Dorado/Medaka is quite good at fixing small-to-medium scale errors. But for lower-error assemblies (e.g. Autocycler), it may not change much.
rrwick.bsky.social
I agree, most real-world MAGs probably have more errors than isolates, especially if low depth. Also, metagenomes may have within-species variation, and then the ideal MAG is (arguably) some sort of consensus. Especially if there is structural variation, this can be a BIG challenge for assemblers.
rrwick.bsky.social
New blog post!

metaMDBG (@gaetanbenoit.bsky.social) and Myloasm (@jimshaw.bsky.social) have had recent releases, so I updated the benchmarks from the Autocycler paper:
rrwick.github.io/2025/09/23/a...

Both tools improved considerably! Time to update your conda environments 😄
Benchmark update: metaMDBG and Myloasm
a blog for miscellaneous bioinformatics stuff
rrwick.github.io
Reposted by Ryan Wick
jimshaw.bsky.social
Preprint out for myloasm, our new nanopore / HiFi metagenome assembler!

Nanopore's getting accurate, but

1. Can this lead to better metagenome assemblies?
2. How, algorithmically, to leverage them?

with co-author Max Marin @mgmarin.bsky.social, supervised by Heng Li @lh3lh3.bsky.social

1 / N
biorxiv-bioinfo.bsky.social
High-resolution metagenome assembly for modern long reads with myloasm https://www.biorxiv.org/content/10.1101/2025.09.05.674543v1
rrwick.bsky.social
Amazing, thanks! Will keep an eye out for this preprint.
rrwick.bsky.social
I haven't yet, but that is absolutely something I should try. I should also more generally educate myself on best practices in telomere assembly, e.g. with that paper Adam linked. This is new to me!
rrwick.bsky.social
Thanks for this - looks interesting!
In the paper you said: "...Illumina sequencing can generate spurious indels within HTs, especially for HT lengths longer than 14 bp." Do you have a sense of how bad this gets for really long homopolymers, e.g. 20+ bp?
rrwick.bsky.social
I'm sure there are more robust ways to go about telomere assembly - I'm not very experienced with T2T eukaryote genome assemblies 😬
rrwick.bsky.social
And my manual telomere fixing was makeshift. I pieced together a few assemblies (mostly from Flye) that extended all the way to the telomeres. And then I manually repaired the telomeres to be exact 6-mer repeats - i.e. I assumed any deviation from the 6-mer was ONT error not real biology.
rrwick.bsky.social
Since all Illumina sequencing involves some PCR (bridge amplification), I also wonder at what length Illumina reads start to fail with homopolymers. Can they reliably sequence 20-mers? 40-mers? 60-mers? It's a hard question to answer if every sequencing tech struggles with these...
rrwick.bsky.social
I too am wary. I suppose the hope is that by limiting changes to long homopolymers, polishing will fix more errors than it introduces. I.e. I'm guessing that ONT's long-homopolymer error rate is greater than cross-sample homopolymer differences. But this is very much unproven!
rrwick.bsky.social
New blog post!

I added a new feature to @gbouras13.bsky.social's Pypolca: homopolymer-only polishing. Potentially useful for cross-sample polishing - early test on Cryptosporidium looks promising.

Check it out here:
rrwick.github.io/2025/09/04/h...
Cross-sample homopolymer polishing with Pypolca
a blog for miscellaneous bioinformatics stuff
rrwick.github.io
Reposted by Ryan Wick
hughcottingham.bsky.social
Pleased to say that our preprint benchmarking Nanopore data for MLST, cgMLST, cgSNP & AMR typing from bacterial isolates is out! TL;DR you can get almost perfect results from 50x depth using live SUP basecalling with a GPU in under 20 hours #microsky#IDsky 🦠🧬🖥️ /1
www.medrxiv.org/content/10.1...
rrwick.bsky.social
However, I hear rumours that ONT might be working on a new move-table-aware bacterial polishing model. See my blog post from Feb for details: rrwick.github.io/2025/02/07/d.... If true, I'll be eager to test it out when released.
rrwick.bsky.social
Minor new release of @nanoporetech.com's Dorado:
github.com/nanoporetech...

It supports using --bacteria when polishing an assembly with v5.2.0 data, which is nice! But if I understand correctly, it's the same bacterial polishing model from Sep 2024, not a new model.
Release v1.0.1 · nanoporetech/dorado
[1.0.1] (4 June 2025) This release introduces support in the --bacteria mode of Dorado polish for data basecalled with v5.2 models and improves the speed of 5mCG_5hmCG calling with v5.0 and v5.2 mo...
github.com
rrwick.bsky.social
Good to know - thanks for clarifying. Makes sense for a tool that's designed to work with big metagenomic datasets. I'm using it a bit out of its domain on a bacterial isolate.
rrwick.bsky.social
The read set was only 240 MB (gzipped), so it is memory hungry. The myloasm docs do acknowledge that it uses more memory than other assemblers.

Also, I ran my tests on an ARM Mac, but the docs suggest that myloasm (specifically the polishing step) will be even faster on x86-64 CPUs with AVX2.
rrwick.bsky.social
Just ran a few more tests through GNU time:
1 thread: 435 seconds, 10.1 GB RAM
2 threads: 238 seconds, 10.0 GB RAM
4 threads: 133 seconds, 10.1 GB RAM
8 threads: 73 seconds, 10.1 GB RAM
16 threads: 49 seconds, 13.3 GB RAM