My data-loader fix just won a $1,000 Vesuvius Challenge Progress Prize
I won a $1,000 Vesuvius Challenge Progress Prize.
The official July 2026 winners page names me for “Zarr 3 read
fixes”: fixing multiscale Zarr 3 reads in the Python vesuvius Volume class and restoring an
opt-in chunk cache. It’s the same work from the chunk-size study I
published two weeks earlier — villa PR #1177,
still open and working through maintainer review as I write this.
What was actually fixed
The vesuvius Python library streams the CT scans researchers use to segment and read the
Herculaneum scrolls. Its Volume class had three problems after the project’s zarr 3 upgrade.
Multiscale volumes — the standard way scrolls are stored, one array per resolution level —
raised a TypeError on every read, because zarr 3 requires string keys where the code still used
integers. Every read did extra, hidden network round-trips re-checking metadata that never
changes. And the chunk cache, which stops you re-downloading the same region twice, had quietly
stopped existing, because zarr 3 removed the class it was built on.
I fixed all three, added regression tests, and — during review — fixed a related zarr-2/zarr-3 compatibility bug a maintainer caught that I’d missed on the first pass. Repeat reads of the same region now come from memory instead of the network, 677× to 1,618× faster depending on the access pattern, measured over the real network against the production store.
Why it’s worth saying out loud
This wasn’t a research result. It’s plumbing — making sure the tool everyone else’s research depends on actually works. The Vesuvius Challenge runs progress prizes explicitly for that kind of contribution, alongside the more visible segmentation and mesh work, and this one was awarded before the PR was even merged, on the strength of the fix and the writeup alone.
If you’re doing open-source infrastructure work and wondering whether “just” a compatibility fix is worth writing up: apparently, yes.