Fluid simulation · mimo-v2.6-flash

Let me build a fluid simulation in a single index.html file. I'll use a grid-based Eulerian fluid solver (Jos Stam's stable fluids) on Canvas 2D with typed arrays, at a bounded resolution (e.g., 200x133 or so), rendering dye to an ImageData scaled up.

Let me plan:
- Grid: width ~ 192, height based on aspect ratio (1200x800 → 1.5 aspect, so 192x128).
- Fields: u, v (velocity), u0, v0 (temp), density r,g,b or single dye with color? Requirement: color selector. Simplest: dye stores RGB. Advect each channel. Or store a single scalar dye per color? Let's store dye as RGB float arrays — 3 arrays. Advection of 3 channels + 2 velocity = 5 advections per step. Fine at 192x128 = 24576 cells.

Steps per frame:
1. Add forces (from drag): add velocity and dye.
2. Advect velocity (semi-Lagrangian).
3. Viscosity/diffusion optional — skip or small. Use vorticity confinement to keep swirls.
4. Project (pressure solve, Gauss-Seidel ~ 20-30 iterations).
5. Advect dye.
6. Dissipate (multiply velocity and dye by decay factor).
7. Render dye to offscreen ImageData, then drawImage scaled to full screen with smoothing.

Boundary conditions: velocity reflect at walls (set to - inward component or zero). For dye, clamp sampling.

Clear: zero dye and velocity.

Pause/Resume: stop stepping, keep rendering.

Color selector: input type=color plus a few preset swatches maybe. Keep simple: <input type="color">.

Initial seed: add some colored dye splats and velocity swirls at load.

Performance: 192x128 grid, Gauss-Seidel 30 iters for projection = 24576*30*2 ≈ 1.5M ops per frame — fine.

Let me write the code carefully.

Grid indexing: idx = x + y*N. Use (x+1) + (y+1)*(W+2) with boundary cells, or handle boundaries manually with clamping. I'll use padded grid of size (W+2)*(H+2) to simplify boundary handling — classic Stam implementation.

Actually simpler: use arrays of size N = (W+2)*(H+2), index i = x + y*(W+2) where x in [0..W+1], y in [0..H+1]. Interior x in 1..W, y in 1..H.

set_bnd(b, x): for x=0..W+1, y=0..H+1: if b==1: x[0,i] = -x[1,i] (left boundary), etc. Interior boundary cells copy.

Let me write Stam's solver functions:

- advect(b, d, d0, u, v, dt): backtrace.
- project(u, v, p, div).
- diffuse skipped (viscosity 0) for performance and responsiveness.

Vorticity confinement: compute curl, then force = eps * h * (N x curl). I'll add it for persistent swirls.

Dissipation: u *= 0.999 etc per frame scaled with dt? Just fixed per-frame factors: velocity decay ~0.995, dye ~0.995 (fade). Dye should "gradually dissipate" — with 60fps, 0.995 → halflife ~138 frames ≈ 2.3s. Maybe dye 0.997, velocity 0.998? But also dye needs to fade visibly. Let's do velocity 0.997, dye 0.996.

Hmm, "Momentum and dye remain visible after the pointer is released and gradually dissipate." So slow decay is good. dye 0.995, vel 0.997.

Rendering: ImageData of size W×H (interior only), fill from dye arrays with a slight background (dark). Draw to offscreen canvas of W×H, then main ctx.drawImage(off, 0, 0, canvas.width, canvas.height) with imageSmoothingEnabled = true (smooth upscale looks nice).

Dye values may exceed 1; clamp. Add background color dark (#05060a). Maybe add slight glow: could boost with a curve. Keep simple.

Pointer handling: pointerdown/move/up, compute delta in canvas pixels → convert to grid velocity units. Injection: for each move, splat dye at position with radius, and velocity splat along drag delta.

Splat function: for cells within radius, gaussian falloff: dye += color * g; u += dx * g.

Units: velocity in grid cells/sec? Stam's advect uses dt * u where u in cells per second... In his code, dt and dx: x - dt*u[i]*N... Let's define velocity in units of cells/second, advect: x = i - dt*u[i] (with dt in seconds). So if dt = 1/60, and u = 100 cells/s, backtrace 1.67 cells. Grid is 192 wide; a drag across screen (1200px) in 0.2s → in grid units, 192 cells over 0.2s = 960 cells/s if attached 1:1. That's fast — semi-Lagrangian handles it (clamp position). We should scale drag velocity: vel = delta_cells / dt but clamp magnitude. Let's compute gridVel = (deltaPx * gridScale) / dtFrame, clamp to like 400 cells/s? Actually typical CFL: dt*u/h... we have no h since velocity in cells/s. Keep max speed ~ 300 cells/s → moves 5 cells/frame at 60fps. That gives nice movement. Maybe clamp to 500.

Actually let's think: splat velocity added each frame during drag; it accumulates. We add force = deltaCells/dt * gaussian, clamp result. Then projection makes it divergence-free, so swirls form.

Vorticity confinement epsilon ~ 0.15? Depends on curl magnitudes. Curl of velocity field in cells/s per cell. With speeds ~300 over 10 cells, curl ~30/s. Force = eps * curl gradient normalized... Standard formula:

curl[i] = (v[i+1,j] - v[i-1,j] - u[i,j+1] + u[i,j-1]) * 0.5 (in units cells/s per cell ≈ /1... since dx=1).
Grad of |curl|: Nx, Ny normalized.
Force: u += dt * eps * (Ny * curl - Nx * ... wait:

N = ∇|w| / |∇|w||; force = eps * (N × w) where w is curl vector (0,0,w) in 2D: F = eps * (N_y * w, -N_x * w)? Cross product N × w with w = (0,0,w): (N_y*w - 0, 0 - N_x*w, ...) → F = (N_y*w, -N_x*w)*eps.

Then clamp. eps ~ 2.0? Let's tune: with dt=1/60, eps=5 → force*dt = 5/60*w ≈ 0.083*30 = 2.5 cells/s per frame. Reasonable. I'll pick eps = 4 and clamp per-frame velocity addition.

Actually, I could compute curl gradient with dx=1. Fine.

Let me also add slight dye diffusion? Not necessary; semi-Lagrangian numerical diffusion blurs anyway.

Resolution choice: 200×133 for 1200×800 (aspect 1.5): choose grid based on canvas aspect: GW = 200, GH = round(200 * h/w) = 133. Cap total cells ~ 30k.

But canvas may resize — keep grid fixed at load (or re-init on resize? Simplest: compute grid on load and on resize just re-render; aspect mismatch stretches slightly. Better: recompute grid on resize with debounce and reseed? Clearing on resize might be jarring but resize is rare. I'll keep grid fixed at initial aspect; drawImage stretches to canvas. Simpler and fine.

Performance per frame: advect velocity (2), project (30 iters over interior ×2 ops), advect dye (3), vorticity (1). ~ 25k cells * ~7 passes ≈ 175k + 30*2*25k = 1.5M for projection. Gauss-Seidel 20 iterations: 1M. Fine at 60fps in JS.

Let's write projection with red-black or simple lexicographic Gauss-Seidel. Lexicographic is fine.

set_bnd for pressure p: b=0 (copy). For velocity: b=1 (x), b=2 (y): reflect → walls: u at left wall = -u[1,y]? In padded arrays: for x=0: u[0,j] = -u[1,j]; x=W+1: u[W+1,j] = -u[W,j]; y=0: u[i,0] = u[i,1]. Good.

Also no-slip: could set u[0,j]=0 for full no-slip; standard Stam uses reflect (free-slip). Fine.

Clear button: zero all dye, u, v, p; also reset pointer state. Should it also zero any pending? Yes.

Pause: stops stepping (requestAnimationFrame continues rendering but skips update). Also stops injection? While paused, dragging — probably should still allow? Spec says pause/resume; keep it simple: paused stops simulation update; pointer drag while paused does nothing visible except maybe nothing. I'll allow injection but no advection — actually injection without stepping looks static. I'll disable stepping but still let splats accumulate? Cleaner: while paused, ignore pointer injection too? Hmm. I'll let injection still happen (it renders immediately) but no advection/projection — gives user feedback. Actually dye injection while paused shows a static blob growing — that's fine and arguably correct.

I'll go: paused → skip update() but pointer splats still applied. That's reasonable.

Color selector: an <input type="color"> plus several preset swatch buttons that also update the color input. Also "rainbow" mode? Keep required: color selector. I'll add presets row.

UI overlay: top-left panel with title, color input, buttons Pause/Resume (toggle text), Clear. Semi-transparent panel, pointer-events auto; canvas below. Make sure drags on panel don't draw on canvas (pointer events on canvas only anyway).

Hint text: "Drag to inject dye".

Initial seeding: a few splats with velocities forming a swirl: e.g., place splats at various positions with colors (use selected color? seed with a palette of a few colors), and velocity in a circulating pattern so it swirls.

E.g., seed: 4-5 splats with different hues (cyan, magenta, orange, green) and tangential velocities around center → vortex.

Let me implement seed():
- positions: (0.3,0.35),(0.6,0.3),(0.5,0.6),(0.7,0.65),(0.4,0.7) with colors [hsl-ish rgb].
- velocity: assign rotational field around center: for splat, u = -dy*k, v = dx*k relative to center → counterclockwise. Plus a couple of random-ish directions.

Also add slight ambient: maybe set initial velocity field as a couple of large-scale eddies (deterministic function) so it swirls immediately.

Let me write code now.

```js
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d');
let W, H, N; // grid interior width/height, stride
let u,v,u0,v0,dr,dg,db,dr0,dg0,db0,p,div,curl;
```

Functions:

```js
function IX(x,y){ return x + y*STRIDE; }
```
Inline index computation for speed.

alloc: size = (W+2)*(H+2).

setBnd(b, x):
```js
function setBnd(b, x){
  const S=STRIDE, Wp=W+1;
  for(let j=1;j<=H;j++){
    x[0 + j*S] = b===1 ? -x[1 + j*S] : x[1 + j*S];
    x[Wp + j*S] = b===1 ? -x[Wp-1 + j*S] : x[Wp-1 + j*S];
  }
  for(let i=0;i<=W+1;i++){
    x[i] = b===2 ? -x[i+S] : x[i+S];
    x[i + (H+1)*S] = b===2 ? -x[i + H*S] : x[i + H*S];
  }
  // corners
  x[0] = 0.5*(x[1] + x[S]);
  x[Wp] = 0.5*(x[Wp-1] + x[Wp]);
  ...
}
```
Wait for b===0 pressure corners copy average — standard. Actually corners for b=1 or 2 with the loop: x[0] would be set by first loop? i loop from 0 covers i=0 row. Let's just do standard Stam: set x[0]=0.5*(x[1]+x[S]) etc. after. Since for b=1, x[0 at row0]... doesn't matter much.

advect:
```js
function advect(b, d, d0, uu, vv, dt){
  for j 1..H, i 1..W:
    let x = i - dt*uu[idx]; let y = j - dt*vv[idx];
    clamp x to [0.5, W+0.5]; y to [0.5, H+0.5];
    i0=floor(x), i1=i0+1, j0=floor(y), j1=j0+1;
    s1=x-i0, s0=1-s1, t1=y-j0, t0=1-t1;
    d[idx] = s0*(t0*d0[i0+j0*S] + t1*d0[i0+j1*S]) + s1*(t0*d0[i1+j0*S]+t1*d0[i1+j1*S]);
  setBnd(b,d);
}
```

project:
```js
function project(uu,vv,p,div,dt? ){
 // standard: div = -0.5*(u[i+1]-u[i-1]+v[j+1]-v[j-1]) / N  ... with dx=1: div = -0.5*(...)
 // p solve: p = (div + p[i-1]+p[i+1]+p[j-1]+p[j+1]) / 4 ... wait standard: (div + sum neighbors)/4 with div defined as -0.5*h^2*...
```
With dx=1: div[idx] = -0.5*(u[i+1]-u[i-1] + v[j+1]-v[j-1]). Then p iter: p = (div + pL+pR+pT+pB)/4? Let's derive: ∇²p = ∇·u. Finite difference: (pL+pR+pT+pB-4p) = div_f where div_f = 0.5*(u[i+1]-u[i-1]+v[j+1]-v[j-1]) (that's ∇·u * dx... since ∇·u ≈ (u[i+1]-u[i-1])/(2dx), dx=1 → same). So p = (pL+pR+pT+pB - div_f)/4.

I set divF = 0.5*(...). Then p = (neighbors - divF)/4.

Then u -= 0.5*(p[i+1]-p[i-1]); v -= 0.5*(p[j+1]-p[j-1]).

Check: u_new = u - ∇p, ∇p ≈ (p[i+1]-p[i-1])/2. Yes.

Alternatively use Stam's with h=1/N... my version with dx=1 is consistent since velocity in cells/s. Let's verify consistency: velocities in cells/s, positions in cells, dt seconds. Yes dx=1 cell.

Gauss-Seidel iterations: 20.

vorticity confinement:
```js
// curl
for interior: curl[idx] = 0.5*((v[i+1]-v[i-1]) - (u[j+1]-u[j-1]));
// gradient of |curl|
for interior: dx = |curl[i+1]|-|curl[i-1]|; dy=|curl[j+1]|-|curl[j-1]|; len=hypot(dx,dy)+1e-5; Nx=dx/len; Ny=dy/len;
 u[idx] += dt * EPS * (Ny * curl[idx]);  // force = eps*(N × w) → (Ny*w, -Nx*w)
 v[idx] += dt * EPS * (-Nx * curl[idx]);
```
Wait sign: F = eps * (N × w) where w = (0,0,w). Cross product (N × w) = (N_y*w_z - N_z*w_y, N_z*w_x - N_x*w_z, ...) = (N_y*w, -N_x*w, 0). Yes as above. That amplifies curl (standard). But sign convention of curl here: w = ∂v/∂x - ∂u/∂y (my curl formula: 0.5*((v[i+1]-v[i-1]) - (u[j+1]-u[j-1])) = ∂v/∂x - ∂u/∂y). Standard 2D vorticity ω = ∂v/∂x - ∂u/∂y. And N = ∇|ω|. Force F = σ (N × ω ẑ)... In standard formulas (Fedkiw), f = σh(N × ω) where ω is the vorticity vector = ω ẑ. N × ωẑ = (N_y ω, -N_x ω, 0). Same. Good.

Hmm, but does this sign actually amplify? Fedkiw's paper: yes with that sign it enhances vorticity. Let me sanity check with a simple 2D case... I'll trust it; if it damps, the sim still works (just less swirling). I could test empirically: seed a vortex and see if it persists. Hard to verify visually via screenshot quickly. Alternative: I can write a quick node test harness! I can extract the JS sim functions and run in node to check e.g. total curl increases with confinement, energy decays, dye advects. That's a good verification approach — but the file must be single index.html. I can still test by copying logic into a temp node script.

Actually a simpler check: run the sim headlessly with node (extract script from index.html via a small node script that evaluates the sim part). Might be complex. Alternative: use browser tool to inspect and take screenshots, sample pixels. The browser tool supports screenshot and inspect (DOM/console). I can add a debug hook: expose window.__sim with sample functions so I can verify "sample the flow after release" — e.g., expose a function to read average velocity in a region. Then use browser action "inspect" to run JS? The inspect action probably returns DOM/console info. Let me check what "inspect" does — likely evaluates something? Not sure of params: action "inspect" with text param maybe. I'll try.

Plan for verification: use browser to screenshot, click, drag (drag action with from/to coords), then screenshot to see dye following drag, and use console/debug hook. I can have the page log diagnostics to console (e.g., window.__diag() returns avg speed / dye mass) and use inspect to read console. Let's see what inspect returns.

Also I can write a quick Node check of the numerics by extracting the script: e.g., `node -e "const html=fs.readFileSync('index.html','utf8'); const js=html.match(/<script>([\s\S]*)<\/script>/)[1]; ..."` but the script references document/canvas. I could guard: if (typeof document !== 'undefined'). Eh — simpler: structure the JS so the fluid core is pure (no DOM), and DOM wiring in an init() called at the end only if document exists. Then node can eval script and run sim steps and print diagnostics. That's a solid verification for: dye advects with velocity, momentum persists after release, clear resets.

Let's do that: wrap DOM part in `if (typeof document !== 'undefined') { ... }` — but the addEventListener etc. Actually in node, `document` undefined → skip. Need canvas/ctx variables inside that block. Fine.

Then a node harness: load script via `new Function` or vm, expose globals via `globalThis`. Use vm.runInThisContext.

Good plan. Let's write the code.

Structure:

```html
<!DOCTYPE html>
<html lang="en">
<head>... styles ...</head>
<body>
<canvas id="c"></canvas>
<div id="panel">...</div>
<script>
/* ===== Fluid core (pure JS, no DOM) ===== */
...
/* ===== DOM wiring ===== */
if (typeof document !== 'undefined') { ... }
</script>
</body>
</html>
```

Expose for testing: `globalThis.FluidAPI = { step, splat, clear, seed, diag, ... }`.

Core API:
- Fluid.init(gw, gh)
- Fluid.splat(x, y, dx, dy, color, radius) with x,y in grid coords (interior, 1..W)
- Fluid.step(dt)
- Fluid.clear()
- Fluid.seed()
- Fluid.dye arrays accessible for rendering: Fluid.u, Fluid.v, Fluid.dr/dg/db, Fluid.W/H/STRIDE.

Rendering in DOM part: build ImageData(W,H), loop interior, write pixels.

Per-frame loop:

```js
function frame(now){
  dt = min((now-last)/1000, 0.033); last=now;
  if(!paused){ handle pending splats; Fluid.step(dt); }
  render();
  requestAnimationFrame(frame);
}
```

Pointer handling: on pointermove while down, compute delta and push splat with position. But if paused, still splat. Let's apply splats immediately in the event handler (splat directly), rather than queueing — simpler. But high-frequency events could apply many splats; that's fine (limit by rate). Actually applying in handler means between frames the dye gets injected with velocity based on instantaneous delta. dt-dependent? Splat velocity: dx in grid cells per second = (deltaPx * gridScaleX)/dtSinceLastMove? Simpler: use fixed mapping: velocity = deltaGridCells * K where K ~ 30? Since splat is an impulse (adds to velocity field, not scaled by frame dt), adding velocity proportional to pointer delta per event: if pointer moves 10 cells in one event, add u += 10*K. With K=6 → 60 cells/s per event... but events fire each frame typically (60Hz), so a fast drag moves maybe 15 cells/event → 90 cells/s added each frame, accumulating over drag → could reach 300+. Since dissipation is slow, it accumulates to high speeds. Let's instead compute target velocity: u += (deltaCells/dtEvent - u[idx]) * g * strength — i.e., blend toward pointer velocity. That's controllable: velocity approaches pointer speed. deltaCells/dtEvent in cells/s. Cap at 400.

Simpler robust approach: velTarget = clamp(deltaGrid / dtEvent, max 500); then u[idx] += (velTarget.x - u[idx]) * g * 0.6. Hmm, but "injects momentum in drag direction" — additive is fine too. I'll do: u[idx] += velTarget.x * g * 0.5, with clamp on field after? Additive accumulates; but each event replaces-ish... Additive could blow up on slow drags (many small events). Actually additive with target speed: each event adds up to full target speed * g → fast accumulation to several hundred cells/s. Semi-Lagrangian handles it, and projection clamps... not really clamped.

Let me use blend approach: u += (target - u) * g, which smoothly drives fluid toward pointer speed — physically like a moving obstacle and very stable. I'll use factor 0.5*g. Combined with dissipation it behaves well. And dye additive: dr[idx] += color.g * g (clamped at render).

Radius: ~ grid 6% of width, gaussian sigma ~ radius/2? Use falloff exp(-d²/(2σ²)) with σ = radius.

Coordinate conversion: canvas rect → grid: gx = 1 + (px/rectWidth)*W; gy = 1 + (py/rectHeight)*H.

target = deltaGrid / dtEvent where dtEvent = (now - lastEventTime)/1000 clamped [1/240, 1/20]? If events come every frame, dt ≈ 1/60 → deltaGrid e.g. 5 cells → 300 cells/s. Good.

Also splat along the segment? Events frequent enough.

Clamp target speed to 600 cells/s? With W=200, crossing screen takes 0.33s at 600. Fine, cap 500.

Dye color: hex → rgb 0..255 → use 0..1 values in field? Use 0..255 directly? Let's store dye 0..1 and multiply color channels. Splat adds color[r] * g * 0.9 per event — accumulates. Then render: value*255 clamped, maybe tone map: c = 255*(1 - exp(-v)) to avoid harsh clipping and give nice additive glow? A tone map makes overlaps blend nicely (like additive light). Let's use v→ 255*(1-exp(-1.2*v))? Hmm, but then dye never fully fades to black? exp(-1.2*0.0001) ≈ 1 → value ~0.0003*255 ≈ 0.08, fine, near black. With background #050510 added. Let's do: r = bg + (255-bg)*(1-exp(-dye)). Simple and looks good.

Dye dissipation: dye *= 0.996 per frame at 60fps → half-life ~173 frames ≈ 2.9s. Reasonable "gradually dissipate". Velocity: 0.997 → half-life ~3.8s. Actually want momentum to persist visibly a while; maybe 0.995 for velocity is 2.3s. Choose vel 0.997, dye 0.994. And apply dissipation scaled: pow(decay, dt*60).

Vorticity EPS: choose 3.0? I'll test with node harness: seed a single vortex, run 300 steps, check mean curl doesn't collapse to near zero and dye keeps swirling (track a dye blob centroid variance?). Let's test: with EPS=0 vs EPS=3, compare total kinetic energy decay and curl.

Actually a good metric: total speed after N steps. And after "release" (no forcing), speed should decay gradually.

Also seed: after 600 steps, does dye still move? Check mean |velocity| > threshold.

Let me write it.

Console diag helper: window.__diag = () => ({meanSpeed, dyeMass, ...}).

Node harness: 
```js
const fs=require('fs'), vm=require('vm');
const html=fs.readFileSync('index.html','utf8');
const js=html.match(/<script>([\s\S]*?)<\/script>/)[1];
vm.runInThisContext(js); // document undefined → skip wiring, but FluidAPI set on globalThis
const F = globalThis.FluidAPI;
F.init(200,133); F.seed(); 
... run steps, print
```
But the script's top-level `const` declarations via runInThisContext are fine. Need `document` check. Also requestAnimationFrame guard.

Careful: inside script, `if (typeof document !== 'undefined')` — in node, document is undefined → typeof returns 'undefined' → skip. But canvas/ctx referenced inside that block only. Good.

Let me write the full file now.

Styles: full-screen canvas fixed, panel top-left with backdrop blur, buttons, color swatches, small legend. Also maybe FPS/step display? Optional, nice: show grid size. Keep minimal but polished.

Now write the code carefully.

```js
'use strict';
/* ===== Fluid core ===== */
const Fluid = (function(){
  let W=0,H=0,S=0;
  let u,v,ut,vt, dr,dg,db, dt_r,dt_g,dt_b, p, dv, curl; // naming conflict dt? use temp arrays named ur,vr etc.
```
Careful naming: avoid `dt` confusion. Use u0,v0,r0,g0,b0.

```js
  function alloc(n){ return new Float32Array(n); }
  function init(gw, gh){
    W=gw|0; H=gh|0; S=W+2;
    const n=S*(H+2);
    u=alloc(n); v=alloc(n); u0=alloc(n); v0=alloc(n);
    r=alloc(n); g=alloc(n); b=alloc(n); r0=alloc(n); g0=alloc(n); b0=alloc(n);
    pr=alloc(n); div=alloc(n); curl=alloc(n);
  }
```

setBnd as above.

advect(bd, d, d0, uu, vv, dt).

project(uu,vv,pr,div,iters).

vorticity(dt, eps).

step(dt):
```js
function step(dt){
  // dissipation applied at end
  vorticity(dt, EPS);
  project(u,v,pr,div,ITER);
  // swap: advect velocity into temp then swap
  advectVel(dt);
  project again;
  advectDye(dt);
  dissipate(dt);
}
```
Standard order (Stam): add forces → diffuse → project → advect velocity → project → advect densities → dissipate → set_bnd.

I'll skip diffuse.

advectVel: advect(1,u0,u,u,v,dt); advect(2,v0,v,u,v,dt); swap u<->u0, v<->v0. Note must use pre-advected u,v for both — advecting u into u0 and v into v0 using u,v (original) is correct since we read u,v and write into u0,v0.

But after first advect(1,...), u unchanged (we write to u0). Good. Then swap.

advectDye: advect(0, r0...) using u,v; then swap r<->r0 etc.

dissipate: multiply u,v by decay factor; multiply r,g,b.

Careful: after swaps, `u` points to what was u0 — need to reassign variables. Since all are `let` module-level within IIFE, swap works.

splat(x,y,fx,fy,cr,cg,cb,rad, mode?): for j/i within radius, g=exp(-d2/(2σ²)); u[idx] += ... I'll implement two flavors: velocity splat with blend toward target:

```js
function splatVelocity(x,y,fx,fy,rad,strength){
  const sigma=rad, s2=2*sigma*sigma;
  const i0=max(1,floor(x-rad)), i1=min(W,ceil(x+rad)), ...
  for j..for i..{ d2=(i-x)^2+(j-y)^2; w=exp(-d2/s2)*strength; u[idx]+= (fx - u[idx])*w; ... }
}
```
Hmm blending with weight including strength — max weight at center = strength (≤1). If strength 0.6, center velocity moves 60% toward target each event. OK.

Actually to ensure "momentum ... remain visible after pointer released and gradually dissipate" — velocity injected remains in field, dissipated slowly. Good.

Dye splat: additive with weight.

Let's just have one function `splat(x, y, vx, vy, color, rad, velStrength, dyeAmount)`.

diag(): returns {speed, mass, maxSpeed}.

seed(): clear then add splats.

Colors as [r,g,b] 0..1.

Seed design: dark background, splats of teal, magenta, amber, lime with rotational velocity around center plus a jet.

```js
function seed(){
  clear();
  const cx=W*0.5, cy=H*0.5;
  const spots=[
    [0.28,0.32,[0.10,0.85,0.90]],
    [0.70,0.30,[0.95,0.25,0.60]],
    [0.62,0.68,[1.00,0.65,0.10]],
    [0.33,0.70,[0.45,0.95,0.35]],
    [0.50,0.48,[0.55,0.35,1.00]],
  ];
  for each: gx=1+s[0]*W ... splat dye rad=W*0.07 amount ~ ...
  // rotational velocity field
  for each interior cell? or splat velocities: 
  // add large-scale vortex: loop all cells: u += -k*(j-cy)*falloff, v += k*(i-cx)*falloff
```
Let's add a couple of analytic vortices to the velocity field directly — nice initial motion:

```js
function addVortex(cx,cy,str,rad){ loop cells within 3rad: d2; w=str*exp(-d2/(2rad^2)); u[idx] += -(j-cy)*w? }
```
Tangential direction: for counter-clockwise: u = -(j-cy)*w*? Actually tangential vector at (dx,dy) is (-dy, dx) for CCW. So u += -dy*w, v += dx*w, with w scaled: w = str/(rad)? Let's set speed = str * exp(...) and direction normalized: u += -dy/d * speed, v += dx/d * speed. Simpler: u += -dy * k * exp(-d2/(2rad²)), v += dx * k * exp(...). With dy up to rad, k=0.5 gives speed up to 0.5*rad*e^-0.5... rad=30 → speed ~9 cells/s*0.6=... Let's compute: max of d*exp(-d²/(2rad²)) at d=rad → rad*e^-0.5=0.6*30=18; times k. k=8 → 144 cells/s. Good. I'll pick k so initial max speed ~150-200 cells/s.

Two vortices of opposite sign at offset positions creates a nice shear/mixing pattern.

Then seed dye along them.

Node test then: run step 600 times, print mean speed over time and dye mass. Verify swirl persists: mean speed after 600 steps still > 10 cells/s; and after 1200 steps it decays gradually (not instantly).

Also test "drag" simulation: apply splat velocity one direction, step 60 frames, measure mean velocity direction (should retain positive x component initially); then splat other direction, check direction changes.

Clear test: after clear, speed and mass ≈ 0.

Alright, write the file.

Rendering details: 
```js
const off = document.createElement('canvas'); off.width=W; off.height=H;
const offCtx = off.getContext('2d'); const img = offCtx.createImageData(W,H);
function render(){
  const d = img.data; let k=0;
  for(let j=1;j<=H;j++) for(let i=1;i<=W;i++){ const idx=i+j*S;
    d[k++] = 6 + 249*(1-Math.exp(-r[idx]*1.1)); ... }
```
Hmm background: bg rgb(6,7,14). fill = bg + (255-bg)*(1-exp(-dye)). Compute per channel with dye = value (0..1+).

Let's do:
```js
function tone(x, bgc){ return bgc + (255-bgc)*(1-Math.exp(-x)); }
```
with x = dye channel value. dye accumulates: per event amount ~0.35*g → several events → 1-2. exp(-1.2)→ 0.7. Fine.

Then main: ctx.imageSmoothingEnabled = true; ctx.drawImage(off, 0,0, cw, ch).

Actually upscaling 200x133 → 1200x800 with bilinear gives blurry but smooth look; that's typical and attractive for fluids. Good.

DPR: set canvas.width = innerWidth * dpr? For 1200x800 viewport, canvas CSS 100vw/100vh. Use devicePixelRatio capped at 1.5 for perf? drawImage upscale is cheap. I'll use dpr = min(devicePixelRatio, 2).

Grid based on aspect: GW = 192 (or compute: pick cell size ~6px: gw = clamp(round(vw/6), 96, 260)). At 1200 → 200, gh = 800/6 ≈ 133. Good: cell px = 6. Cap: gw*gh <= 40000.

Resize handler: keep grid (aspect stretch if window aspect changes a lot) — or re-init grid and reseed on significant aspect change. Simplest robust: on resize, update canvas size only; grid stays. Aspect stretch acceptable. Actually a big window aspect change would distort fluid visibly (stretch). Rare; acceptable. But let's handle: if aspect changes >25%, recompute grid and re-seed? Losing user's drawing on resize is a bit annoying but resizing is transient. I'll do: on resize just canvas resize; keep grid. Less surprising.

Hmm, but if someone loads in a tall narrow window, gw from vw/6 fine.

UI panel:

```html
<div id="panel">
  <div class="row title">Fluid &amp; Dye</div>
  <div class="row">
    <label class="swatch-label" for="color">Color</label>
    <input type="color" id="color" value="#33e0ff">
    <div class="swatches">... buttons with data-color ...</div>
  </div>
  <div class="row">
    <button id="pause">Pause</button>
    <button id="clear">Clear</button>
  </div>
  <div class="hint">Drag on the canvas to inject dye &amp; momentum</div>
</div>
```

Swatches: 6 preset colors; clicking sets color input and current color.

Pointer events: canvas.addEventListener('pointerdown', ...) with setPointerCapture; track lastX,lastY,lastT. pointermove: if down, compute.

Also support touch: pointer events cover it; add touch-action: none on canvas.

Now code the handler:

```js
let down=false, lastX=0,lastY=0,lastT=0;
canvas.addEventListener('pointerdown', e=>{ down=true; canvas.setPointerCapture(e.pointerId); lastX=e.clientX; lastY=e.clientY; lastT=performance.now(); splatAt(e.clientX,e.clientY,0,0); });
function move(e){ if(!down) return; const now=performance.now(); const dtm=Math.max(8, Math.min(100, now-lastT))/1000; ... }
```

Convert: 
```js
const rect = canvas.getBoundingClientRect();
const gx = 1 + (e.clientX-rect.left)/rect.width * W;
const gy = 1 + (e.clientY-rect.top)/rect.height * H;
const dxg = (e.clientX-lastX)/rect.width * W;
const dyg = (e.clientY-lastY)/rect.height * H;
let vx = dxg/dtm, vy = dyg/dtm; clamp magnitude to 500.
Fluid.splat(gx,gy,vx,vy,color,rad, velStrength, dyeAmt);
```
rad = max(3, W*0.045) ≈ 9 cells at W=200. sigma 9 cells → ~54px diameter on screen. Good.

Multiple events per frame: fine.

Also, when pointer moves fast, injection along segment only at event points; events ~ each frame, fine.

Add: on pointerup/cancel → down=false.

Also prevent default to avoid scrolling; touch-action:none.

Pause button toggles text "Pause"/"Resume" and class.

Clear: Fluid.clear() (keeps seed? No—Clear removes dye and resets velocity; next drag starts new flow). So clear → all zeros. Then user drags → fresh flow. Good. Also render immediately.

Should Clear re-seed? No — spec: "Clear removes dye and resets velocity; the next drag can start a new flow." So no seed after clear.

Now, one concern: after Clear with no dye, background is plain — fine, hint visible.

Initial seed happens on load.

Also maybe add "Seed" button? Not required. Skip (or include as extra? Keep required minimal: color, pause, clear). I'll keep just required + swatches (part of color selector).

Let's also add keyboard: space toggles pause, C clears? Nice extra, low risk.

FPS meter maybe in panel (small). Optional — could help verify responsiveness. I'll add tiny stats line: "200×133 · 60 fps". It's informative.

Now write the whole file.

Projection iterations: 24. Performance: 24 * 200*133 = 638k inner loop iterations for p, plus 2 passes. Fine.

Wait — gauss-seidel with 24 iterations at 200 wide might leave residual pressure but OK visually.

Edge case: dye arrays named r,g,b conflict with nothing. But I used `b` as boundary flag param name in functions — use `bd`.

Also global `p` vs pointer... fine.

Let me write out the code fully.

```js
'use strict';
const FluidAPI = (function(){
  let W=0,H=0,S=0,ready=false;
  const EPS = 3.0, ITER = 24;
  let u,v,u0,v0, dr,dg,db, r0,g0,b0, pr, dv, curl;
  ...
  return { init, splat, step, clear, seed, diag, fields getters... };
})();
globalThis.FluidAPI = FluidAPI;
```

For rendering I need access to dr,dg,db and S,W,H: expose `get fields(){ return {W,H,S,r:dr,g:dg,b:db,u,v}; }` or methods: `width()`, etc. I'll expose an object `f` referencing? Since arrays are reallocated on init, expose getter functions.

Simplest: expose `state()` returning {W,H,S,r:dr,g:dg,b:db}. Allocation happens once (init called once), so returning the same references is fine.

diag(): {speed: mean|v|, maxSpeed, mass: sum dye, steps}.

Now setBnd implementation with padded grid:

```js
function setBnd(bd, x){
  const w1 = W+1, h1 = H+1;
  for(let j=1;j<=H;j++){
    x[0 + j*S]   = bd===1 ? -x[1 + j*S]     : x[1 + j*S];
    x[w1 + j*S]  = bd===1 ? -x[w1-1 + j*S]  : x[w1-1 + j*S];
  }
  for(let i=1;i<=W;i++){
    x[i]        = bd===2 ? -x[i+S]    : x[i+S];
    x[i + h1*S] = bd===2 ? -x[i+H*S]  : x[i+H*S];
  }
  x[0]         = 0.5*(x[1] + x[S]);
  x[w1]        = 0.5*(x[w1-1] + x[w1-1 + S]);   // hmm
  ...
```
Standard Stam:
```
x[0] = 0.5*(x[1]+x[S])? 
```
Actually Stam's set_bnd: 
```
for (int i=1;i<=N;i++) {
  x[IX(0 ,i)] = b==1?-x[IX(1,i)]:x[IX(1,i)];
  x[IX(N+1,i)] = b==1?-x[IX(N,i)]:x[IX(N,i)];
  x[IX(i,0 )] = b==2?-x[IX(i,1)]:x[IX(i,1)];
  x[IX(i,N+1)] = b==2?-x[IX(i,N)]:x[IX(i,N)];
}
x[IX(0,0 )] = 0.5*(x[IX(1,0 )]+x[IX(0,1)]);
x[IX(0,N+1)] = 0.5*(x[IX(1,N+1)]+x[IX(0,N)]);
x[IX(N+1,0)] = 0.5*(x[IX(N,0 )]+x[IX(N+1,1)]);
x[IX(N+1,N+1)] = 0.5*(x[IX(N,N+1)]+x[IX(N+1,N)]);
```
Note corner uses x[IX(1,0)] which was set in the i-loop. Fine — I'll replicate exactly (loops over i=1..N covering both axes).

advect clamping: x = clamp(i - dt*uu, 0.5, W+0.5); i0=floor(x), i1=i0+1. If x = W+0.5 → i0=W, i1=W+1 (valid padded). Good.

Let me also make sure advect for dye uses bd=0 (Neumann: copy).

Write splat:

```js
function splat(x,y,vx,vy,col,rad,velK,dyeAmt){
  const s2 = 2*rad*rad;
  const i0=Math.max(1, Math.floor(x-rad)), i1=Math.min(W, Math.ceil(x+rad));
  const j0=Math.max(1, Math.floor(y-rad)), j1=Math.min(H, Math.ceil(y+rad));
  for(let j=j0;j<=j1;j++) for(let i=i0;i<=i1;i++){
    const dx=i-x, dy=j-y, d2=dx*dx+dy*dy;
    if(d2 > rad*rad*4) continue;
    const w = Math.exp(-d2/s2);
    const idx = i+j*S;
    u[idx] += (vx - u[idx]) * w * velK;
    v[idx] += (vy - v[idx]) * w * velK;
    const a = w*dyeAmt;
    dr[idx] = Math.min(6, dr[idx] + col[0]*a);
    ...
  }
}
```
Clamp dye at 6 to bound work? doesn't affect work. Fine, prevents inf.

velK: strength per event, ~0.55. But note events at 60Hz each blend 0.55*w toward target — converges quickly to pointer velocity. Good.

Dye amount per event: 0.5*w*color? With 60 events during a drag → tons of dye, saturating. Since blend happens continuously, dye clamps at 6 anyway (tone map saturates to ~white). Hmm — saturating to white loses color identity. Let's lower: dyeAmt = 0.25 per event but also cap at 3. During a drag over one spot for 1s, it saturates — that's acceptable/typical (bright core). But it may go white quickly. Use dyeAmt ~ 0.12 per event and cap 4: over 0.5s (30 events) at w=1 → 3.6 → saturates. The tone map with multiplier: tone(x) = 255*(1-exp(-1.0*x)) → x=1 → 63% bright; x=2 → 86%; x=3 → 95%. So color channel ratios preserved somewhat; if all channels additive with same shape... at x_r=0.9*3 etc, ratios distort toward white. Acceptable; looks like a bright core with colored edges — typical.

Alternative: don't clamp, just tone map. Repeated drags to same spot saturate → white core. Fine.

Actually maybe better: tone map with lower gain so accumulation doesn't blow: gain 0.9.

Now dye dissipation ensures fading.

Let's write render loop with stats update every 500ms.

Node test harness — but careful: script uses `requestAnimationFrame` inside DOM block only. Also uses `performance` inside handlers only. The core uses Math only. 

One more: the core uses `globalThis.FluidAPI = ...` — in browser it becomes window.FluidAPI, fine.

Also `'use strict'` at top of script — assigning to globalThis is explicit, fine.

Now let's write everything.

For the DOM block, wrap in `if (typeof document !== 'undefined' && document.getElementById) { main(); }`.

Let me write final code.

Rendering stats: meanSpeed from diag each 500ms.

Also want a small "swirl indicator"? no.

Let me write the file.

One consideration for "Bound simulation resolution and work per frame": grid cap 200x133 ≈ 26.6k cells; projection 24 iters; dt clamped ≤ 1/30; splat radius bounded. Also cap number of pointer events processed per frame? Not needed.

Actually, I should consider doing injection per frame rather than per event to bound work — pointermove events could fire many times. Bound: accumulate pointer deltas in the handler (just update pending position/delta), and apply one splat per animation frame. That bounds work per frame and also handles coalesced events nicely. Let's do that: handler stores latest position + accumulated delta + time; in frame loop (before step), if pending && (down or released-in-this-frame?) apply splat once with delta since last frame. That gives velocity = deltaCells/frameDt which is exactly pointer speed. 

Implementation:
```js
let pending = null; // {x, y, dx, dy, t}
onmove: if(!down) return; accumulate dx += e.clientX-lastX ... ; store x,y (latest).
frame: if(pending){ apply splat using delta/frameDt ...; pending=null }
```
But if paused, frame still runs → splat applies. Good.

frameDt: use dt from rAF (clamped). delta in grid cells / dt → cells/s. Clamp to 500.

If pointer hasn't moved (dx=0,dy=0) but down: still inject dye at position? Pressing without moving → dye blob appears (velocity target 0 → drags fluid to rest locally). That's OK: inject dye with small amount, velocity target 0 (blends toward zero — acts like obstacle). Maybe skip velocity if delta==0 but add small dye? I'll add dye only if moved or always? A tap should leave a dot of dye — nice. I'll apply dye splat always when down, velocity only when |delta| > 0.

Edge: frame loop applies splat once per frame → dye per frame 0.12 → during 1s hold ~7 → saturates. Reduce dye per frame to 0.08 with cap 4? Hold 1s → 0.08*60 = 4.8 → saturate at cap 4. Hmm. Let's make dye continuous rate: dye += amt * dt * rate where rate ~ 5/s → 1s hold adds 5? Similar. It's fine to saturate a held spot — user expects bright blob. Colors: to preserve hue at high intensity, maybe tone map with min across channels? Overkill.

Compromise: dye amount per frame 0.10, cap 3.0, tone gain 1.0. Bright core acceptable.

Let's write.

```js
function frame(now){
  raf = requestAnimationFrame(frame);
  let d = (now - last)/1000; last = now;
  if(!(d>0)) d = 1/60;
  d = Math.min(d, 1/30);
  if(pending) applyPending(d);
  if(!paused){ FluidAPI.step(d); frames++; }
  render();
  ...
}
```
If tab hidden, rAF stops; fine.

Note: while paused, dt used for splat velocity = clamped d.

pending handling: 
```js
function applyPending(d){
  const st = FluidAPI.state();
  const gx = 1 + (pending.x/rect.width)*st.W ...
  vx = pending.dx/rect.width*st.W / d
```
where pending.dx in CSS px accumulated since last frame. clamp speed 500.

Edge: d used for splat is the frame dt; accumulation happened over that frame. Correct.

Now clear pending on pointerup? On pointerup, leftover delta should be applied — frame will apply it anyway since pending still set (we set pending on move regardless of down? Only while down). On up, we set down=false but pending remains → applied next frame. Fine.

Let's write the final file now. I'll be careful with syntax.

Also add `aria-label`s? minor.

Panel styling: fixed top-left, background rgba(10,12,20,.72), backdrop-filter blur(10px), border 1px rgba(255,255,255,.12), border-radius 14px, padding 14px, font system-ui, color #e8ecff, width ~250px.

Buttons: padding 8px 14px, radius 8, cursor pointer, background gradient subtle; hover.

Color input: width 44 height 32, padding 0, border none, background transparent, cursor pointer.

Swatches: 22px circles with border.

Hint: font-size 12px, opacity .65.

Stats: monospace 11px opacity .6.

Cursor: crosshair on canvas.

Now write.

After writing, run node harness tests, then browser checks.

Let me write the HTML file.

Additional detail for diag: compute mean speed over interior and total dye mass.

Write code:

```js
function diag(){
  let sum=0, mx=0, mass=0;
  for(let j=1;j<=H;j++) for(let i=1;i<=W;i++){
    const idx=i+j*S;
    const s=Math.sqrt(u[idx]*u[idx]+v[idx]*v[idx]);
    sum+=s; if(s>mx) mx=s;
    mass += dr[idx]+dg[idx]+db[idx];
  }
  const n=W*H;
  return {meanSpeed:sum/n, maxSpeed:mx, mass, W, H};
}
```

Node test script (temp file, not index.html): /tmp/job-flpSsn/test.js — hmm, should I leave extra files in cwd? The task says write index.html; extra test file is probably fine but cleaner to put in /tmp. I'll put harness in /tmp/test-fluid.js.

Let's write files.

Test scenarios in harness:
1. init, seed → meanSpeed > 20, mass > 10.
2. run 600 steps of dt=1/60 with no forcing → after: meanSpeed > 5 (momentum persists, dissipates gradually) and dye mass still > some fraction (persists but decreasing). Compare mass at step 0/600 decreasing but not near zero.
3. drag: splat velocity (vx=200,vy=0) at center with radius → step 5 → mean vx positive (u component mean > 0).
4. second drag in another direction: splat vy large → after steps, mean |v| increased relative to mean |u|? Or check mean v positive.
5. clear → meanSpeed < 1e-6, mass < 1e-6.
6. after clear, splat again → mass > 0 and speed > 0 (fresh flow starts).

Also verify dye follows drag: track dye centroid displacement after velocity applied: seed dye blob, apply uniform-ish velocity via splat, step 30, centroid x moved right.

I'll implement centroid of a channel (r).

Let's write everything now.

Code for step ordering detail: vorticity uses current u,v; project; advect vel; project; advect dye; dissipate.

Write:

```js
function step(dt){
  if(!(dt>0)) dt=1/60;
  vorticity(dt);
  project();
  advect(1, u0, u, u, v, dt);
  advect(2, v0, v, u, v, dt);
  let t=u; u=u0; u0=t; t=v; v=v0; v0=t;
  project();
  advect(0, r0, dr, u, v, dt); ... swap
  dissipate(dt);
}
```

Wait: advect(1,u0,u,u,v,dt) writes into u0 while reading u — but then advect(2,v0,v,u,v,dt) reads u (unchanged) — correct.

project() uses pr, dv internal arrays.

dissipate: 
```js
const du = Math.pow(0.997, dt*60), dd = Math.pow(0.994, dt*60);
```
Math.pow per step is fine.

Hmm: with vorticity confinement injecting energy, equilibrium. EPS tune via test: measure meanSpeed at step 600 with EPS 0 vs 3.

vorticity:
```js
function vorticity(dt){
  // curl
  for interior: curl[idx] = 0.5*((v[idx+1]-v[idx-1]) - (v[idx+S]-v[idx-S])); 
```
wait curl = ∂v/∂x - ∂u/∂y = 0.5*((v[i+1]-v[i-1]) - (u[j+1]-u[j-1])). u[j+1] = u[idx+S], u[j-1] = u[idx-S]. Yes.

```js
  for interior:
    const dx = Math.abs(curl[idx+1]) - Math.abs(curl[idx-1]);
    const dy = Math.abs(curl[idx+S]) - Math.abs(curl[idx-S]);
    const len = Math.sqrt(dx*dx+dy*dy) + 1e-5;
    const nx = dx/len, ny = dy/len;
    const c = curl[idx];
    u[idx] += dt*EPS*(ny*c);
    v[idx] += dt*EPS*(-nx*c);
```
Note setBnd not needed for curl (interior only) but curl array borders are stale — we only read interior neighbors (idx±1, idx±S) which for i=1 reads idx-1 = i=0 cell of same row — that's a border cell, stale from previous step. Better to compute curl including border cells (set to 0) or just fill borders each step. Simplest: loop over i=0..W+1, j=0..H+1 computing curl with clamped neighbors? For border cells just set curl=0 (they'd be garbage otherwise but we read them at i=1). Actually reading curl at i=0 (border) when computing force at i=1: if border curl=0 that's fine (approximation). So: first loop over all cells setting curl=0 for borders and computing interior. Or compute curl for i=0..W+1 using clamped indices — i=0 uses idx+1 and idx-1 → idx-1 = i=-1 → out of array! So must clamp. Easiest: fill entire array with 0 first (fill(0) is fast: 26k), then compute interior. Or just compute interior and rely on border zeros from previous... no, garbage.

Do: curl.fill(0) — cheap — then compute interior. Then force loop over interior only (reads interior curl neighbors which are computed). Good.

Force loop reads curl[idx±1] where idx at i=1 → curl[0] = 0 (filled). Fine.

Now writing final code. Let me write the file.

Also note: after velocity splat, dye splat. Then step.

Number formatting for stats.

Let me write it.

Also add: `canvas.addEventListener('contextmenu', e=>e.preventDefault())`? not needed.

Time to write. I'll produce the full HTML.

For the seed function, splat dye at spots with the *color* param, then add two vortices. Also add a directional jet for initial motion.

Also make seed use colors different from selector default? Seed colors as chosen palette.

Let me now write.

Also one thing: `clear()` should also reset pr,dv (irrelevant) and curl — set all to 0.

Write file.

Then run node harness, then browser.

I'll write index.html now with careful full content.

Extra: to keep "Pause" from freezing dye injection rendering — fine.

Keyboard: space toggles pause (prevent default scroll), 'c' clear.

Let's go.

Details for render loop stats: update `#fps` text every 500ms: `${st.W}×${st.H} · ${fps} fps · speed ${meanSpeed.toFixed(0)}`.

Now the actual file content.

const $ = id => document.getElementById(id);

Panel HTML ids: colorInput, pauseBtn, clearBtn, stat, swatches container.

Write code.

I'll write it in one go.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Fluid &amp; Dye</title>
<style>
  html,body{margin:0;height:100%;overflow:hidden;background:#05060a;font-family:...}
  #c{position:fixed;inset:0;width:100vw;height:100vh;display:block;cursor:crosshair;touch-action:none;}
  #panel{position:fixed;top:16px;left:16px;...;user-select:none;}
  ...
</style>
</head>
<body>
<canvas id="c"></canvas>
<div id="panel">...</div>
<script>...</script>
</body>
</html>
```

Now full JS. Let me be meticulous.

I'll now write the file.