# Deep Dive #2 — The MPAS Developer-Experience Kit: making NCAR's next-generation model adoptable *NSF NCAR / RAL · strategy working document · draft July 2026* **One line:** NCAR has bet its modeling future on MPAS and stopped active WRF development — but regional MPAS is hard to adopt. Build the containerized, documented, cloud-runnable onboarding layer that turns "expert-only" into "productive in an afternoon." This is a pure developer-experience play, which is exactly your lane. --- ## Why this is *your* project Of the ten ideas, this one has the tightest fit to what you already do: - **Containers** — your workspace has `containers/` and `custom_containers/`; the core of this kit is Apptainer/Docker environment definitions that make MPAS reproducibly buildable. - **Developer experience** — the whole point is onboarding, quickstarts, sane defaults, and removing friction. That's a DevX discipline, not an atmospheric-science one. - **Visualization** — `wrf-viewer` and `webgl_viewer` translate directly: MPAS uses an *unstructured* mesh, and good quick-look visualization of that mesh (via UXarray/WebGL) is one of the sharpest current pain points and a natural showcase for your skills. You are not the person who needs to advance MPAS *science*. You are exactly the person who should own MPAS *adoption*. --- ## The problem, precisely NCAR has publicly shifted development effort "entirely to MPAS," keeping WRF only in maintenance mode given its huge install base. MPAS is also gaining operational momentum (NOAA is evaluating it for a next-generation unified system; The Weather Company runs it in its GPU "GRAF" system). But adoption is throttled: - **Regional/limited-area MPAS "is only getting started"** and community contributions "are just starting to come in" (NCAR's own framing). Regional MPAS covers only a fraction of WRF's capability today. - **The onboarding cliff is real:** building MPAS (Fortran + MPI + PnetCDF/PIO), assembling the init workflow, writing correct namelists/streams, running, and then *analyzing unstructured-mesh output* is a multi-day expedition for a newcomer — versus WRF's two decades of tutorials, forums, and muscle memory. - **The analysis toolchain is immature:** unstructured meshes don't drop into the tools people know. UXarray (from NCAR's Project Raijin) exists but the "load MPAS output → make a map in five lines" path isn't paved. Every WRF user NCAR wants to migrate hits this wall. Lowering it is a force multiplier on the institution's single most important modeling bet. --- ## Why a public institution should build this (and why it's fundable) Adoption infrastructure is a **community good that no vendor will fund** — there's no product to sell, but the entire ecosystem's value depends on it. That's precisely what NSF's open-source-ecosystem programs exist for, and it compounds NCAR's own strategic investment in MPAS. It's cheap relative to its leverage: a small DevX effort can unlock a large research community. --- ## What exactly to build — the kit A layered "zero-to-productive" path, each layer independently valuable: **A. Reproducible environments.** Apptainer (NCAR's HPC standard) and Docker definitions that build a known-good MPAS-Atmosphere toolchain — pinned compilers, MPI, and the PnetCDF/PIO I/O stack — so "it builds on my machine" stops being a rite of passage. This is the foundation and the piece most squarely in your wheelhouse. **B. A 10-minute quickstart.** An opinionated, numbered path: pull the container → fetch a small init dataset → run a pre-baked limited-area case → see output → hand off to analysis. Ruthless removal of decision points a newcomer can't yet make. **C. Annotated reference configs.** A working limited-area `namelist.atmosphere` and `streams.atmosphere` with every important block explained inline — the thing that today lives only in experts' heads and scattered forum posts. **D. An analysis starter (the payoff).** A UXarray/xarray script that opens MPAS unstructured output and produces a map in a few lines — and, as a stretch, a WebGL quick-look viewer for the native mesh (your `webgl_viewer` experience directly applies). This is the "it actually works, end to end" moment that converts a skeptic. **E. Contribution + governance scaffolding.** A clear path for the community to add cases/configs — which is the on-ramp to idea #7 (open-source ecosystem governance) and turns the kit from a one-off into a self-sustaining ecosystem. ### The "aha" you're engineering ``` today: git clone → read 40 pages → install 6 libraries → 3 failed builds → hand-edit namelist → MPI errors → ??? → (give up) kit: apptainer pull → make run-demo → make analyze → a map of your first MPAS forecast, in one sitting ``` ### Phased build - **MVP (this scaffold + a real container):** environment defs, quickstart, annotated configs, analysis starter — the skeleton (being scaffolded now) filled in and validated on real hardware. - **v1:** a genuinely one-command limited-area demo on Derecho/Casper *and* on a laptop/cloud; UXarray recipes for the common fields; a hosted tutorial (Project Pythia style). - **v2:** WebGL unstructured-mesh quick-look; a config generator (guided namelist creation); community contribution pipeline live. --- ## Technical risks & unknowns - **The MPAS build recipe needs a domain expert to verify** exact flags, versions, and the init/preprocessing workflow (the scaffold marks these `# TODO: verify`). This is the main correctness risk and where you'd pair with an MMM/MPAS engineer. - **"10 minutes" is hardware-dependent** — be honest that a meaningful case needs real compute; provide a truly tiny demo case for laptops and a realistic one for HPC. - **UXarray maturity** — capable but evolving; some recipes may need workarounds. That friction is itself worth documenting (and feeding back upstream). - **Staying current** — MPAS moves; the kit needs a maintenance commitment or it rots. This is an argument *for* the ecosystem/governance layer, not against the kit. ## What success looks like A new user goes from `git clone` to a plotted forecast in one sitting; RAL applied teams adopt the container as their standard MPAS environment; and the kit becomes the officially-pointed-to on-ramp in MPAS tutorials. Measured by: time-to-first-forecast, container pulls, and community-contributed cases. --- # Positioning & funding — #2 ## The narrative "NCAR has stopped developing WRF and put its future in MPAS — but every researcher we want to bring along hits a wall of build errors, cryptic configs, and analysis tools that don't speak unstructured mesh. A small developer-experience investment removes that wall and multiplies the return on NCAR's single biggest modeling bet. This is cheap, it's concrete, and it's the kind of infrastructure NSF's open-source programs are built to fund." ## Target sponsors & why each buys | Sponsor | The pitch to them | Vehicle | |---|---|---| | **NSF PESOSE** (was POSE) | Fund the *ecosystem & governance* around a mature open-source model — exactly this, for MPAS | NSF 26-506 PESOSE; Phase I to scope, Phase II to establish | | **NSF CSSI** | Adoption tooling as sustained national cyberinfrastructure | CSSI solicitation | | **NOAA EPIC** | NOAA is eyeing MPAS operationally; a strong community on-ramp serves the UFS transition | EPIC community funding; UIFCW26 venue | | **NCAR internal / MMM** | Protects the ROI on the MPAS bet; low cost, high strategic value | Internal strategic funds / lab investment | **PESOSE is the standout, underused lever:** it funds *governance and sustainability around already-mature open-source products* rather than the science — a funding path that doesn't compete with shrinking core research dollars, and MPAS is a textbook candidate. ## The differentiated value prop, by audience - **To NCAR leadership:** you already spent the money building MPAS; this is the cheap multiplier that makes the community actually use it. - **To NSF:** durable open-source ecosystem infrastructure with clear national benefit. - **To NOAA:** a healthier MPAS community de-risks the operational transition. ## Partnerships to line up first MMM (the MPAS developers — essential technical partners and validators), Project Pythia / Unidata (tutorials & hosting), and 2i2c/Pangeo if a cloud-runnable JupyterHub path is included. ## The ask (illustrative) A **1–2 FTE, ~12-month** effort to ship the container + quickstart + analysis recipes and a hosted tutorial, plus a PESOSE Phase I to scope the governance model. Small enough to start internally and grow into external funding. ## Risks to the funding case - "Isn't this just docs?" → No: it's reproducible environments + validated configs + an analysis toolchain, i.e., engineering, not documentation. Lead with the container and the working end-to-end demo. - Maintenance burden → address head-on with the ecosystem/governance (PESOSE) framing so it's funded to persist. - Dependence on MMM cooperation → make MMM a named partner from the start; this is *their* adoption problem too. --- ## How #1 and #2 relate They're complementary, not competing bets. **#2 (MPAS DevX)** is lower-risk, faster, cheaper, and can start *internally today* — a credibility-builder and a natural fit to begin implementation on. **#1 (verification service)** is the higher-ceiling, more strategically dominant play with the broadest funding base. A sensible sequence: **start #2 to build momentum and demonstrate delivery, while positioning #1 for the larger external funding.** The scaffold being generated now is the first concrete step on #2.