A short Development Seed deck (8 slides) for a NASA technical group that is deciding how to virtualize Earthdata collections going forward. It argues for direct VirtualiZarr parsing over relying on pre-generated DMR++ sidecars:
- DMR++ opens faster only because the chunk scan already ran:
build_dmrppandHDFParserboth walk the chunk index withH5Dchunk_iter. - That scan is a small, one-time cost next to generating, storing, rebuilding and fixing a sidecar for every granule.
- Sidecars repeat the same metadata for every granule and can be stale or wrong, the file itself can't be.
- VirtualiZarr's parsers are small, modular Python behind one interface, while
DMR++ generation lives in a C++ data server (BES). HDF4 is the exception:
a more robust
HDF4Parserneeds OPeNDAP's help.
The source material is the "DMR++ vs. native HDF parsing in VirtualiZarr" review doc.
- Two paths, one result. Both paths produce the same
ManifestStore, and both include the chunk scan - Same scan, different time. The
build_dmrppandHDFParsercode side by side - The whole bill. The scan as one small item in each path's costs
- Duplication. MUR SST sidecars: 87% repeated day to day, and copies disagree across BES versions
- A second-hand copy of the file. Documented sidecar problems and ~15% coverage
- Maintainability. Lines of code, the
Parserprotocol, and the HDF4 ask to OPeNDAP - Performance. 2026 HDF parser benchmarks
- Recommendation. Direct parsing by default, DMR++ as an opt-in cache
Requires Node 18+.
npm install
npm run dev # http://localhost:3030 (live-reloads as you edit slides.md)- Presenter view with speaker notes: http://localhost:3030/presenter/
- Overview of all slides: http://localhost:3030/overview/
npx slidev export slides.md --output slides.pdf
npx slidev export slides.md --format png --output png # one PNG per slideExporting uses playwright-chromium, which is already a dev dependency.
slides.pdf in this folder is a recent export.
- Slides are separated by
---. Every slide uses one of two DevSeed layouts inlayouts/:devseed(label, heading, body) ordevseed-statement(one big line). In each slide,# H1is the small uppercase label and## H2is the heading. Wrap key phrases in**bold**to show them in DevSeed blue. - The first slide takes its layout from the headmatter at the top of
slides.md(layout: devseed-statement). <!-- ... -->at the end of a slide becomes its speaker notes. The notes hold the numbers, methods and sources behind each slide.styles/devseed.cssis the DevSeed theme, copied from the CNG Forum 2026 deck.styles/index.cssholds this deck's own components (flow diagram, cost ledger, duplication bars, lines-of-code bars, recommendation cards).setup/shiki.tsforces a dark code theme because code sits on navy panels.package.jsonpinsfuse.jsto 7.1.0 throughoverrides. Newer versions make Slidev's "go to slide" menu show all the time.
All measurements were taken in Oct 2026.
- Code excerpts and line counts: shallow clones of
OPENDAP/bes and
zarr-developers/VirtualiZarr
(
main, 4fc1bc5). Non-test.cc/.hand.pyfiles, counted withwc -l. - Duplication slide: MUR SST L4 (
MUR-JPL-L4-GLOB-v4.1, PO.DAAC). The granule count (8,914) is from CMR. Sidecars are<granule>.nc.dmrppfrom the PO.DAAC archive, which needs Earthdata Login credentials in~/.netrc. Compared granules: 2025-06-01 vs 2025-06-02, plus 2010-06-01 and 2018-06-01 to check the BES version anddeflateLevel. - Problems, coverage and benchmarks: the GitHub issues and PRs cited in each slide's speaker notes.
To re-run the duplication measurements on any two consecutive sidecars:
python3 scripts/metadata_vs_refs.py day1.dmrpp day2.dmrpp # chunk refs vs. other metadata, and how much matches
python3 scripts/granule_specific_bytes.py day1.dmrpp day2.dmrpp # bytes unique to the granule vs. repeatedslides.md the deck
slides.pdf latest PDF export
layouts/ DevSeed Slidev layouts
styles/ DevSeed theme + deck-specific styles
setup/ Slidev setup (code highlighting theme)
public/ DevSeed logo
scripts/ DMR++ duplication measurement scripts