# Deep Dive — Browser-Native Plume Visualization: making hazard dispersion intuitive *NSF NCAR / RAL · strategy working document · draft July 2026 · (new idea, proposed as portfolio addition)* **One line:** Dispersion model output — smoke, toxic release, ash, radiological plume — is trapped in desktop tools and static maps that only specialists can read. Build a novel, browser-native engine that renders 2D and 3D plumes intuitively, colored by concentration mapped to *danger levels*, tunable in real time — so a responder, a regulator, or the public instantly sees where it's dangerous and how much. A working proof-of-concept demo of exactly this (a tunable Gaussian-plume visualization with danger-banded color) is being built alongside this document as `plume-demo.html`. --- ## Why this is *your* project — the tightest fit in the whole portfolio This idea sits at the intersection of two things already in your workspace: - **`AQ_WATCH`** — air-quality forecasting/plumes. Concentration fields are the native data type here. - **`webgl_viewer` / `wrf-viewer`** — browser-native, GPU-accelerated geoscience visualization. That's precisely the engine this needs. Add RAL's institutional dispersion heritage (the National Security Applications line ran transport-and-diffusion / plume modeling — e.g., VTHREAT-style work for the National Capital Region), and this is an idea where **you already have both the domain data and the exact technical skill.** Of everything discussed, this is the one you could prototype fastest and own most completely. (It's why the demo is worth building today.) --- ## The problem, precisely When something disperses into the air — wildfire smoke, a chlorine tank rupture, an industrial stack exceedance, volcanic ash, a CBRN release — the people who must act need one thing fast: **where is it, and how dangerous is it there?** Today that's badly served: - **Dispersion output lives in specialist desktop tools.** HYSPLIT, CALPUFF, AERMOD, and national-security dispersion codes produce authoritative fields, but their outputs are static images or GIS layers that require an expert to interpret and can't be explored interactively by a decision-maker in the moment. - **Concentration ≠ danger, visually.** A rainbow contour of µg/m³ doesn't tell an incident commander or a resident what to *do*. The mapping from concentration to **actionable danger bands** (safe → hazardous → life-threatening, per pollutant-specific thresholds) is usually absent or buried. - **3D is where plumes actually live, but tools show 2D.** Plumes loft, sink, channel between buildings, and pool in valleys. A ground-level 2D contour hides the vertical structure that determines who's exposed. Genuine, intuitive 3D plume rendering in a browser is rare. - **No shared, embeddable, public-facing view.** There's no lightweight, trustworthy, browser-native component that a public-safety site, an AQ portal, or an emergency dashboard can drop in to show a live plume to non-experts. That's a **visualization and communication gap** sitting on top of good physics — the kind of gap a viz-strong team at a trusted institution can close quickly and distinctively. --- ## What exactly to build A **browser-native plume visualization engine** — rigorous underneath, immediately legible on top. **A. Intuitive 2D + 3D rendering.** - 2D plan view: ground-level (or any-level) concentration as an intuitive danger-colored field over a map, with source, wind, scale, and distance-to-threshold readouts. - 3D view: the plume as a translucent volume you can orbit — WebGL volumetric raymarching or layered isosurfaces — so vertical lofting/channeling/pooling is visible. This is the novel, differentiating piece and exactly your `webgl_viewer` territory. **B. Concentration → danger-level color, tunable.** Discrete, colorblind-safe danger bands with pollutant-specific thresholds (AQI for PM2.5, AEGL/ERPG for toxics, etc.), and the thresholds are **user-tunable** — the demo's core interaction. A viewer sees *where* and *how* dangerous at a glance, and can ask "what counts as dangerous for *this* substance?" **C. Model-agnostic input.** - **Fast interactive core:** an analytic Gaussian plume model (what the demo uses) for instant tunability and teaching/what-if — real physics, real-time. - **Authoritative mode:** ingest real dispersion output (HYSPLIT, CALPUFF, national-security codes, AQ_WATCH fields) as gridded/Zarr/netCDF for operational use. - **Urban microscale (stretch):** couple to CFD/LES (RAL's **FastEddy** resolves flow between buildings) for street-level plume behavior — a capability almost no browser tool has. **D. Embeddable + open.** A clean, self-contained component (like the demo) that public-safety dashboards, AQ portals, and emergency-management tools can embed — and that RAL can point to as a trusted public artifact. ### Phased build - **Phase 0 — the demo (now):** a self-contained, tunable Gaussian-plume visualization with danger-banded 2D (and 3D) views. Proves the concept and is the pitch artifact. - **Phase 1 — real data:** ingest HYSPLIT/CALPUFF/AQ_WATCH gridded output; time animation; multiple pollutants with correct thresholds. - **Phase 2 — 3D urban:** FastEddy/CFD coupling for building-scale plumes; terrain. - **Phase 3 — operational/embeddable:** hardened, embeddable component + API; partner deployment (an AQ agency, an emergency-management portal, a national-security customer). --- ## Why a public institution wins here Hazard communication to the public and to responders must be **trusted, neutral, transparent, and scientifically defensible** — you can't run a shelter-in-place decision off a vendor demo. NCAR/RAL has the dispersion physics, the AQ data, the verification culture, and the neutrality; and an *open, embeddable* public-good component is something a commercial vendor has little incentive to build. ## Technical risks & unknowns - **3D volumetric rendering performance** across devices — the demo will show whether raymarching is robust; layered slices are the fallback. - **Threshold correctness matters a lot** — danger bands must use validated, substance-specific standards (AQI/AEGL/ERPG); getting these wrong is a safety issue, so they need domain review. - **Real dispersion I/O is heterogeneous** — HYSPLIT/CALPUFF formats and grids differ; ingestion is real work (ties to the ML-ready-data idea #3). - **Over-trust risk** — an intuitive plume can be believed too precisely; the UI must show uncertainty and model provenance. ## What success looks like An AQ portal or emergency dashboard embeds the component to show a live plume the public can actually understand; responders use the 3D view to see vertical exposure; and RAL has a distinctive, cited, open hazard-visualization capability that no vendor matches. --- # Positioning & funding — Plume Visualization ## The narrative "When something toxic is in the air, the model already knows where it's going — but the people who have to act can't read the model. RAL can build the browser-native engine that turns any dispersion forecast into an instantly legible, danger-colored, 2D-and-3D picture that a responder or a resident understands in five seconds — rigorous underneath, intuitive on top, and open." ## Target sponsors & why each buys | Sponsor | The pitch to them | Vehicle | |---|---|---| | **DHS / DTRA / DOD** | Rapid, intuitive plume common-operating-picture for CBRN & incident response | National-security contracts; RAL's existing dispersion/national-security line | | **EPA / state air agencies** | Public-facing AQ & smoke visualization people can act on | EPA / air-quality programs; ties to AQ_WATCH | | **NOAA** | Smoke (HRRR-Smoke), volcanic ash, and IDSS visualization | NOAA weather program / EPIC | | **FEMA / emergency mgmt** | Hazmat & wildfire-smoke response dashboards | DHS/FEMA | | **Chemical Safety Board / industry** | Facility release modeling & community communication | Regulatory / commercial | | **NSF** | Novel geoscience visualization as open infrastructure | CSSI | ## The differentiated value prop - **To responders:** a plume they can read and orbit in the browser, in the moment. - **To the public:** hazard communication that actually communicates — danger, not µg/m³. - **To funders:** a distinctive, open, embeddable capability built on RAL's dispersion physics and viz strength. ## The ask (illustrative) This is the **cheapest, fastest idea to prove** — the Phase-0 demo essentially exists as a prototype today. Ask for **~1 FTE for ~6–9 months** to turn the demo into a real-data-ingesting, multi-pollutant, embeddable component with one partner deployment, then pursue DHS/EPA/NOAA funding for the operational and 3D-urban phases. ## Risks to the funding case - "It's just a visualization" → no: it's rigorous dispersion physics + validated danger thresholds + novel 3D rendering; the demo makes that tangible. - Threshold liability → use only validated standards and show provenance/uncertainty. - Fit to the portfolio → it's a natural companion to #5 (evacuation/impact) and #3 (data) and reuses #1's verification ethos. --- ## Suggested portfolio placement On the briefing's matrix criteria, this would likely score high on **feasibility** and **ease** (it's your exact skill set and a demo already exists), high on **strategic fit** (trusted public hazard communication, distinctive), and solid on **fundability** (DHS/EPA/NOAA/industry). It plausibly lands in the **upper-middle of the top tier** — I can add it to the interactive matrix as an 11th idea if you want it scored alongside the rest.