Emergence

The same idea across systems

Many simulations spend their time resolving details that do not change the answer. The emergence engine asks each model for an error claim and a cost, picks the cheapest one meeting the request, and unfolds when its indicator or certificate fails. Expensive fine models can be folded into reusable closure tables checked on held-out points.

Claims say whether they are asymptotic, validated or rigorous. An audit compares selected answers with the reference model. If the requested accuracy is unreachable, the result says so.

Try it in the browser

• Light and atmosphere: change a sphere's size, material or error tolerance. The real Rust ladder selects a Rayleigh expansion, a resonance-aware folded table, or the full Mie series. Every plotted result is checked against the series, with claimed and observed errors shown together.
• Fluid motion: run the native f64 spectral CPU solver through WebAssembly on a small periodic grid. Compare a planar Taylor–Green vortex with its exact energy decay, or inspect a slice through the 3D vortex and its resolution warning.
• Engineering design: edit fins and airflow in the original motor-driver cooling graph. Electrical losses, the temperature feedback loop and laminar channels feed requirements with uncertainty. A nominally passing trace drop is honestly undecided; out-of-regime flow makes the thermal result unavailable.

What the native workspace contains

The public repository brings together incompressible and compressible fluids, water/air interfaces, convection, photons and spectral rendering, heat and materials, chip and CPU design, CAD and a shared engineering project graph. The chip flow includes a small CPU running Fibonacci; the CAD examples link geometry to mass, printable parts and thermal requirements.

These systems have different maturity. Atmosphere and water optics are model building blocks, not a validated weather forecast. The repository documents which couplings exist and which remain incomplete.

Fluid motion you can inspect

A slice through an evolving periodic flow. The arrows show velocity in the slice; orange and cyan distinguish opposite vorticity. The exact planar preset provides a separate quantitative check. The 3D view uses the same CPU solver, with a small grid suitable for a browser.

Light transport and rendering

A retained native renderer output from the same workspace. Rust computes the scene geometry, light transport and final pixels. Wood and linen maps are generated appearance estimates; the scene is a rendering experiment with documented limitations. The source, settings and provenance are public.

Measured gains, with their limits

A retained native cloud-scattering benchmark was 10.7× faster than evaluating the full Mie series everywhere after a one-off table build; every sampled node agreed to 4.7 × 10⁻¹². Those are measurements for that benchmark and hardware, not browser speed claims.

For certified fluid resolution at Re = 200 and t = 0.5, a 10⁻³ requested L² tolerance selected 16³ with a 3.5 × 10⁻⁴ bound; the measured distance to a 48³ comparison was 8.7 × 10⁻⁵. Adaptive refinement did not beat the best fixed grid on Taylor–Green. Both the gain and that negative result are retained in the validation write-up.

What a claim covers

A numerical error claim applies inside a model and its assumptions. It does not certify a physical device or remove uncertainty from estimated material properties. The browser fluid grids are illustrative and manually selected; the native certified-resolution ladder is documented separately. The design graph carries the rigor of each contributing model through to its requirement status.