Double pendulum · laguna-s-2.1

Let me build a double pendulum simulation with a fading trail. I'll write this as a self-contained HTML file with inline CSS and JavaScript, using a canvas for rendering and a stable integration scheme (RK4) for the equations of motion.

Let me plan the implementation:

1. Physics: Double pendulum with two equal masses, equal rod lengths, gravity 9.81, initial angles 120° and -10° from downward vertical, zero initial angular velocities.

The equations of motion for a double pendulum (point masses, massless rods):

Let θ1, θ2 be angles from vertical. m1=m2=m, L1=L2=L.

The Lagrangian gives:
θ1'' = (-g(2m1+m2)sin(θ1) - m2·g·sin(θ1-2θ2) - 2sin(θ1-θ2)·m2·(θ2'²·L2 + θ1'²·L1·cos(θ1-θ2))) / (L1·(2m1+m2 - m2·cos(2θ1-2θ2)))

θ2'' = (2sin(θ1-θ2)·(θ1'²·L1·(m1+m2) + g(m1+m2)cos(θ1) + θ2'²·L2·m2·cos(θ1-θ2))) / (L2·(2m1+m2 - m2·cos(2θ1-2θ2)))

With m1=m2=m, L1=L2=L:

θ1'' = (-g(3m)sin(θ1) - m·g·sin(θ1-2θ2) - 2sin(θ1-θ2)·m·(θ2'²·L + θ1'²·L·cos(θ1-θ2))) / (L·(3m - m·cos(2θ1-2θ2)))

Dividing by m:
θ1'' = (-g·3·sin(θ1) - g·sin(θ1-2θ2) - 2sin(θ1-θ2)·(θ2'²·L + θ1'²·L·cos(θ1-θ2))) / (L·(3 - cos(2θ1-2θ2)))

Similarly for θ2''. Actually let me use a general formula that handles arbitrary masses/lengths, which is cleaner.

Let me define the standard equations:

For the double pendulum with point masses:
- m1, m2 masses
- L1, L2 rod lengths
- θ1, θ2 angles from vertical (downward = 0)
- g gravity

The equations (from the Lagrangian):

θ1' = ω1
θ2' = ω2

Numerator for θ1'':
θ1_num = -g(2m1+m2)sin(θ1) - m2·g·sin(θ1-2θ2) - 2sin(θ1-θ2)·m2·(ω2²·L2 + ω1²·L1·cos(θ1-θ2))

denom = L1·(2m1+m2 - m2·cos(2θ1-2θ2))

θ1'' = θ1_num / denom

θ2_num = 2sin(θ1-θ2)·(ω1²·L1·(m1+m2) + g(m1+m2)cos(θ1) + ω2²·L2·m2·cos(θ1-θ2))

denom = L2·(2m1+m2 - m2·cos(2θ1-2θ2))

θ2'' = θ2_num / denom

With equal masses and lengths, this simplifies but I'll keep the general form for clarity.

2. Integration: RK4 (4th order Runge-Kutta) which is stable and accurate. Time step like 1/60 * something, let me use dt = 0.01 or smaller, and substeps to ensure stability. Actually with RK4 and dt=0.01 it should be fine. Let me use dt = 0.005 with RK4.

Actually, for a double pendulum at high energy (120° and -10°), we need small steps. Let me use dt around 0.005 or 0.01 with RK4. The initial angle of 120° is quite large (near the top), so the system has significant energy. RK4 with dt=0.005 should be stable.

3. Rendering: Canvas with scaling. Need to keep both rod lengths constant and pendulum visible. The pendulum can swing quite far (120°), so I need to make sure the canvas is large enough. The max reach is 2L (both rods extended). I'll set up a scaling factor.

Let me set L = 1 (in sim units), so the max reach is 2 units. I'll scale the canvas so that 2 units maps to most of the canvas. Let me use a canvas of 800x600, with scale such that the pendulum is well visible. With L=1, the full extent is 2 units. I'll use a scale of about 200 px per unit, giving 400 px for full extension. Actually that might be too big. Let me use scale ~150 px/unit, giving 300 px for full extension — fits nicely in 600 height.

Let me make the canvas responsive or fixed 800x600. I'll make it fixed at 800x600 for simplicity, or make it fill the window. Let me make it fill the window with dynamic sizing.

Actually, let me make canvas fill the screen and compute scale dynamically based on canvas size so the full extent (2L) fits with margin.

4. Trail: A fading trail at the lower bob. I'll store points with timestamps/ages and fade them. Or use a circular buffer of recent positions with decreasing opacity. I'll store a list of positions and render them with decreasing alpha based on age/index.

For the "fading trail" effect: keep an array of lower bob positions, each point fades over time. I'll cap the trail length and render with gradient of opacity.

A nice approach: store points with a "birth time" and on each render, compute age = now - birthTime, if age > trailDuration, remove it. Render each segment with alpha proportional to (1 - age/trailDuration).

5. Controls: Pause/Resume button, Reset button.

Let me write the code.

Let me think about the canvas setup: I'll create a full-window canvas. The pivot is at some point. Let me place the pivot near the top center. In simulation, the pivot is at origin (0,0), with y pointing down (or up?). Let me use standard graphics: y down. The pendulum hangs downward, so θ=0 is straight down (positive y direction in canvas).

Positions:
- Pivot: (0, 0) in sim
- Bob1: (L1·sin(θ1), L1·cos(θ1))  — with θ from downward vertical
- Bob2: (L1·sin(θ1) + L2·sin(θ2), L1·cos(θ1) + L2·cos(θ2))

In canvas, y is down, so this maps directly if pivot is at canvas center-top area.

Let me place pivot at (canvasWidth/2, 100) and scale.

I'll compute scale = min(canvasWidth, canvasHeight) * 0.4 / (2*L) roughly, so the pendulum fits with margin.

Let me write the full implementation.

For the trail fading, I'll keep an array `trail` of {x, y, t} where t is the timestamp. On each frame where unpaused, I add the current lower bob position. Then render lines with alpha based on age.

Actually, to make the trail continuous and fade nicely, let me add points at a certain rate (not every frame necessarily, but every frame is fine). I'll keep the last N points or points within a time window.

Let me use a time-based trail: trailDuration = 5 seconds. Add point each frame (or when enough time passed). Render each point's alpha = (trailDuration - age) / trailDuration. Cap total points.

For visual color, a "colorful fading trail" — I'll use rainbow colors or a gradient. "Colorful fading trail" suggests the trail has colors. Let me make the trail use a hue that cycles, or use a gradient from one color to another. A nice effect: hue based on age (older = cooler color like blue/purple, newer = warm). Or I could cycle hue over the trail length for a rainbow effect.

Let me do: for each point, hue = (age fraction * 360) or based on index. I'll use a colorful gradient along the trail. Let me make newer points brighter/warmer and older ones fade to transparent with shifting hue.

Let me make each trail segment colored with hue interpolating. I'll do a rainbow trail where hue = (index/trailLength)*360, with alpha fading to 0 at the oldest.

Let me write it now.

Plan for the code structure:
- HTML: canvas + controls (buttons)
- CSS: style the page, center canvas, style buttons
- JS: 
  - Physics constants and state
  - Derivative function (returns dθ1, dω1, dθ2, dω2)
  - RK4 step function
  - Simulation variables
  - Animation loop (with requestAnimationFrame, but use a fixed dt accumulator for physics)
  - Render function (draw pivot, rods, bobs, trail)
  - Event handlers for pause/resume/reset
  - Initial conditions setup

For the animation loop with fixed timestep physics, I'll use a time accumulator pattern. But since this is a physics sim, I want the physics dt fixed. I'll use requestAnimationFrame and accumulate real time, stepping physics with fixed dt. To keep it simple and stable, I'll step multiple sub-steps per frame.

Actually, for simplicity and determinism, let me run physics at a fixed rate (e.g., 120 Hz, dt=1/120≈0.00833) using a fixed timestep accumulator based on real elapsed time, but when paused, stop stepping.

Let me implement:
```
let lastTime = performance.now();
let accumulator = 0;
const dt = 1/120; // physics timestep
const maxFrame = 0.25; // max frame time to avoid spiral

function loop(time) {
  const elapsed = (time - lastTime) / 1000; // seconds
  lastTime = time;
  if (!paused) {
    accumulator += elapsed;
    // cap accumulator
    if (accumulator > maxFrame) accumulator = maxFrame;
    while (accumulator >= dt) {
      rk4Step(dt);
      accumulator -= dt;
    }
    // add trail point
    addTrailPoint();
  }
  render();
  requestAnimationFrame(loop);
}
```

Wait, if paused, I still want to render (and fade trail if I want the trail to fade even while paused? Probably not necessary). Let me keep trail static while paused. Actually "fading trail" — let me make the trail fade based on age regardless, so it's always visible. But while paused, the bob isn't moving so no new points added; existing points continue to age and fade. That's fine. Actually simpler: add points only when unpaused, and age/fade always. That works.

Hmm, but if I age always, while paused the trail fades away which might be odd visually but acceptable. Let me fade only based on age which happens automatically as time passes. Fine.

Actually, to keep it simple and nice, let me make the trail points have a fixed lifespan and fade. Let me set trailDuration = 4 seconds.

Let me also handle the scaling: L1 = L2 = 1 (units). Max extent from pivot = 2. I'll compute scale so 2 units fits in canvas with margin.

Let me write the code now. I'll make a nice clean implementation.

For colors: pendulum — dark/medium colors with some contrast. Let me use a dark background (midnight), rods in a contrasting color, bobs as circles with maybe a gradient, and a colorful trail.

Let me make:
- Background: deep blue/space
- Rods: steel/gray or white
- Bobs: larger top bob colored, smaller lower bob. Add a subtle gradient/shine.
- Trail: colorful rainbow fading.

Let me code.

Pivot: a small square/circle with a mount.

Let me write the file.

I'll set initial angles: θ1 = 120° = 120 * π/180, θ2 = -10° = -10 * π/180.

Note: 120° from downward vertical means the rod is more than horizontal (60° past horizontal, leaning up toward the left if positive). This is a high-energy chaotic start. Good for demonstrating coupled motion.

Let me write the full HTML.

One consideration: numerical stability. With 120° initial angle, the system is chaotic but total energy should be conserved. RK4 with dt=1/120 ≈ 0.0083 should preserve energy well enough for smooth playback. Let me maybe use a slightly smaller dt for safety, like 1/200. With substepping in the accumulator loop, when unpaused it can do multiple RK4 steps per frame. Let me use dt = 1/240 ≈ 0.00417. That's quite stable. Performance is fine for a simple 2-DOF sim.

Actually 1/120 with RK4 is plenty for this. Let me use dt = 1/120. If there's visible energy drift, I can reduce. Let me go with 1/120 and substep.

Let me make the trail a "colored" trail using HSL hue cycling.

Let me write the render for trail: iterate points, for each segment from point[i] to point[i+1], set strokeStyle with hue and alpha.

Let me define trail point: {x, y, age} where I store the timestamp when added. On render compute alpha = 1 - age/trailDuration, hue = based on age (e.g., hue = 240 + age fraction * 120, or rainbow).

For rainbow: hue = (1 - age fraction) * 360? Let me do newer points = warm (red/orange), older = cool (blue/purple), matching "fading". hue = 0 (red) at newest... actually let me cycle hue across the trail for a colorful effect: hue = (index / count) * 360. That gives a rainbow. Combine with alpha fade. That looks nice and "colorful."

Let me go with: hue based on position in trail (rainbow), alpha based on age (fade out).

Let me code it all.

Let me write the file now.

I need to make sure canvas resizes with window. I'll add a resize handler.

Let me also make sure the pendulum stays visible — the scale computation ensures the full reachable area fits.

Let me write it.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Planar Double Pendulum</title>
<style>
  :root {
    --bg: #0b1020;
    --panel: rgba(18, 24, 42, 0.85);
  }
  * { margin: 0; padding: 0; box-sizing: border-box; }
  html, body { height: 100%; }
  body {
    background: radial-gradient(ellipse at top, #122040 0%, #0b1020 70%);
    color: #e8ecf4;
    font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
    overflow: hidden;
    display: flex;
    align-items: center;
    justify-content: center;
  }
  .app {
    position: relative;
    width: 95vw;
    max-width: 1000px;
    height: 80vh;
    max-height: 720px;
  }
  canvas {
    width: 100%; height: 100%;
    display: block;
    background: transparent;
  }
  .ui {
    position: absolute;
    top: 14px; right: 14px;
    display: flex; gap: 10px;
  }
  button {
    background: var(--panel);
    color: #e8ecf4;
    border: 1.5px solid #4a62a0;
    border-radius: 10px;
    padding: 9px 16px;
    font-size: 14px;
    cursor: pointer;
    transition: all .15s ease;
  }
  button:hover { background: #24325a; border-color: #6fa8dc; }
  button:active { transform: translateY(1px); }
  .toggle-on { background: #4a62a0; }
  .legend {
    position: absolute; bottom: 12px; left: 14px;
    font-size: 12px; color: #9fb0d0; line-height: 1.5;
  }
  .legend span { color: #6fa8dc; }
</style>
</head>
<body>
<div class="app">
  <canvas id="pendulum"></canvas>
  <div class="ui">
    <button id="pause">Pause</button>
    <button id="reset">Reset</button>
  </div>
  <div class="legend">
    <div><span>m</span>1 = <span>m</span>2 = 1 · <span>L</span>1 = <span>L</span>2 = 1 · <span>g</span> = 9.81</div>
    <div>Initial: θ1 = 120° · θ2 = −10° · <span>ω</span>1 = <span>ω</span>2 = 0</div>
  </div>
</div>
<script>
(() => {
  const canvas = document.getElementById('pendulum');
  const ctx = canvas.getContext('2d');
  let W = canvas.width, H = canvas.height;

  // Simulation parameters
  const G = 9.81;
  const m1 = 1, m2 = 1;
  const L1 = 1, L2 = 1;

  // Initial conditions (radians)
  const deg = Math.PI / 180;
  const THETA1_0 = 120 * deg;
  const THETA2_0 = -10 * deg;

  // State
  let theta1 = THETA1_0, theta2 = THETA2_0;
  let omega1 = 0, omega2 = 0;

  // Physics: returns derivatives [dθ1, dω1, dθ2, dω2]
  function derivatives(t1, w1, t2, w2) {
    const s1 = Math.sin(t1), s2 = Math.sin(t2);
    const s12 = Math.sin(t1 - t2);
    const c12 = Math.cos(t1 - t2);
    const c1 = Math.cos(t1);
    const denom1 = L1 * (2*m1 + m2 - m2*Math.cos(2*t1 - 2*t2));
    const denom2 = L2 * (2*m1 + m2 - m2*Math.cos(2*t1 - 2*t2));
    const num1 = -G*(2*m1+m2)*s1 - m2*G*Math.sin(t1 - 2*t2)
                 - 2*s12*m2*(w2*w2*L2 + w1*w1*L1*c12);
    const num2 = 2*s12*(w1*w1*L1*(m1+m2) + G*(m1+m2)*c1 + w2*w2*L2*m2*c12);
    return [w1, num1/denom1, w2, num2/denom2];
  }

  const DT = 1/120;
  function rk4Step(dt) {
    const a = derivatives(theta1, omega1, theta2, omega2);
    const k1_0 = a[0], k1_1 = a[1];
    // state at half step
    let t1, w1, t2, w2;
    const b = derivatives(theta1 + 0.5*dt*a[0], omega1 + 0.5*dt*a[1],
                          theta2 + 0.5*dt*a[2], omega2 + 0.5*dt*a[3]);
    const c = derivatives(theta1 + 0.5*dt*b[0], omega1 + 0.5*dt*b[1],
                          theta2 + 0.5*dt*b[2], omega2 + 0.5*dt*b[3]);
    const d = derivatives(theta1 + dt*c[0], omega1 + dt*c[1],
                          theta2 + dt*c[2], omega2 + dt*c[3]);
    theta1 += dt/6*(a[0] + 2*b[0] + 2*c[0] + d[0]);
    omega1 += dt/6*(a[1] + 2*b[1] + 2*c[1] + d[1]);
    theta2 += dt/6*(a[2] + 2*b[2] + 2*c[2] + d[2]);
    omega2 += dt/6*(a[3] + 2*b[3] + 2*c[3] + d[3]);
  }

  // Trail
  const trail = [];
  const TRAIL_TIME = 4.0; // seconds of history
  function addTrailPoint() {
    const pos = bobPos();
    trail.push({x: pos.x, y: pos.y, t: performance.now()});
  }
  // clean old trail points by time
  function cleanTrail(now) {
    while (trail.length && (now - trail[0].t)/1000 > TRAIL_TIME) trail.shift();
  }

  // Positions (sim coords, y down)
  function bobPos() {
    const x1 = L1 * Math.sin(theta1);
    const y1 = L1 * Math.cos(theta1);
    const x2 = x1 + L2 * Math.sin(theta2);
    const y2 = y1 + L2 * Math.cos(theta2);
    return {top: {x:x1,y:y1}, lower: {x:x2,y:y2}};
  }

  // Rendering
  let paused = false;
  function layout() {
    const dpr = Math.min(window.devicePixelRatio || 1, 2);
    canvas.width = W = Math.round(canvas.offsetWidth * dpr);
    canvas.height = H = Math.round(canvas.offsetHeight * dpr);
    ctx.scale(dpr, dpr);
  }

  function screenScale() {
    // fit 2*L into canvas with margin
    const extent = 2*L1 + 0.3;
    return Math.min(W, H) / extent / (window.devicePixelRatio||1)... 
  }
```

Hmm, the scaling with devicePixelRatio gets confusing. Let me simplify: use backingStore sized to W x H in canvas pixels, but draw using CSS pixels by setting ctx transform appropriately. Actually since I call ctx.scale(dpr,dpr) after setting canvas.width/height = offsetWidth*dpr, the drawing coordinate system is back in CSS pixels (because ctx.scale(dpr,dpr) makes 1 unit = dpr canvas pixels = 1 CSS pixel). Wait:

canvas.width = offsetWidth * dpr (canvas backing pixels)
ctx.scale(dpr, dpr) — this scales the drawing by dpr, so 1 canvas drawing unit = dpr backing pixels = 1 CSS pixel visually. Yes. So after ctx.scale(dpr,dpr), coordinates are in CSS pixels. Good. But I also need to re-set transform each frame since scale accumulates? ctx.scale persists across frames. I should reset transform at start of render. Let me use setTransform(1,0,0,1,0,0) then ctx.scale(dpr,dpr) — but if devicePixelRatio changes it's an edge case; I'll call setTransform(dpr,0,0,dpr,0,0) directly. Actually simpler: set canvas backing store to CSS-pixel size and accept slight blur on retina. For a sim that's fine. But let me do DPR properly with setTransform.

Let me restructure render:
```
function render() {
  const px = window.devicePixelRatio || 1;
  if (canvas.width !== canvas.offsetWidth*px || canvas.height !== canvas.offsetHeight*px) layout();
  ctx.setTransform(px,0,0,px,0,0); // reset to CSS-pixel coords
  ...
}
```

But layout() already sets the size; I should recompute on resize. Let me just call layout() on resize and also each frame cheaply check. Simpler: listen to resize event and call layout. And in render just setTransform.

Let me compute the scale and pivot position in CSS pixels:
```
const px = window.devicePixelRatio || 1;
const extent = 2*L1 + 0.3;
const scale = Math.min(W, H)/extent; // in backing pixels... 
```
This is getting messy with DPR. Let me keep canvas backing store in CSS pixels (canvas.width = offsetWidth, no DPR scaling) to simplify math. The result may be slightly blurry on high-DPI but it's acceptable for a simulation and avoids transform confusion. Actually, let me do proper high-DPI rendering cleanly:

- canvas.width = cw (CSS pixels * dpr), canvas.height = ch
- In render: ctx.setTransform(dpr, 0, 0, dpr, 0, 0). Now drawing coords are in CSS pixels. 
- scale computed in CSS pixels: scale = Math.min(cw/H... 

OK let me define in CSS pixel space. Let csw = canvas client width (CSS px), csh = client height. scale in CSS px per sim unit. I'll compute using csw/csh. The canvas backing store is csw*dpr by csh*dpr but setTransform(dpr..) maps CSS px to backing px. 

Let me store csw, csh (CSS dimensions) and compute scale from them.

```
function resize() {
  csw = canvas.clientWidth;
  csh = canvas.clientHeight;
  const dpr = window.devicePixelRatio || 1;
  canvas.width = Math.round(csw * dpr);
  canvas.height = Math.round(csh * dpr);
  // recompute scale, pivot
  const extent = 2*L1 + 0.4;
  scale = Math.min(csw*0.95, csh*0.92) / extent;
  scale = Math.min(scale, 320); // cap visual size
  pivotX = csw/2;
  pivotY = csh*0.22;
  needRedraw = true;
}
```

Wait capping scale at 320 might cut off. Let me not cap and just fit. Actually if screen is large, scale grows making bobs big. That's fine. Let me cap bob radius instead. Let me cap scale so it's reasonable, maybe cap at 300.

In render:
```
function render() {
  const dpr = window.devicePixelRatio || 1;
  ctx.setTransform(dpr,0,0,dpr,0,0);
  ctx.clearRect(0,0, csw, csh);
  // draw trail
  ...
  // draw rods, bobs
  const p = bobPos();
  const sx1 = pivotX + p.top.x*scale;
  const sy1 = pivotY + p.top.y*scale;
  const sx2 = pivotX + p.lower.x*scale;
  const sy2 = pivotY + p.lower.y*scale;
  ...
}
```

Good.

Let me now write trail rendering. Trail points stored in sim coordinates (x, y). To draw in screen coords: sx = pivotX + pt.x*scale, sy = pivotY + pt.y*scale.

Render trail: for i from 0 to trail.length-2, draw segment pt[i] -> pt[i+1]. Color and alpha.

```
function drawTrail() {
  if (trail.length < 2) return;
  const now = performance.now();
  ctx.lineCap = 'round';
  for (let i = 0; i < trail.length-1; i++) {
    const a = trail[i], b = trail[i+1];
    const frac = i/(trail.length-1); // 0 newest front? depends order
    // trail newest at end. So older=front, newer=back.
    const ageFrac = (now - a.t)/(1000*TRAIL_TIME); // 0..1
    const hue = (1-frac)*0 + frac*360; // rainbow along trail
    const alpha = Math.max(0, 1 - ageFrac);
    ctx.strokeStyle = `hsla(${hue},90%,60%,${alpha})`;
    const ax = pivotX + a.x*scale, ay = pivotY + a.y*scale;
    const bx = pivotX + b.x*scale, by = pivotY + b.y*scale;
    ctx.beginPath();
    ctx.moveTo(ax,ay); ctx.lineTo(bx,by);
    ctx.lineWidth = 6;
    ctx.stroke();
  }
}
```

To make a smooth thick trail, I could draw wider lines or use a gradient band. Let me use lineWidth increasing with age for a nice tapered look, or keep constant. Let me vary width: width = lerp(2, 7, alpha). 

Let me refine: each segment width proportional to its alpha so the trail tapers at the end (oldest = thinnest/transparent). Good visual.

Let me set width = alpha * 8 + 1.

Let me also add a softer outer glow by drawing a slightly larger, more transparent stroke first. Optional. Keep it clean.

Let me also make colors vibrant.

Now the bobs: draw circles. Lower bob slightly smaller. Add highlight.

Pivot: a small bracket/circle at pivotX,pivotY.

Let me draw:
- Rod1 from (pivotX,pivotY) to (sx1,sy1), lineWidth 5, color #5a7acc with gradient? Use a grayish-blue. 
- Rod2 from (sx1,sy1) to (sx2,sy2).
- Bob1 at (sx1,sy1), radius R1; Bob2 at (sx2,sy2), radius R2 = smaller.
- Pivot: small circle or a triangular mount.

Let me set R1 = 0.09*scale (clamped), R2 = 0.07*scale. Clamp to reasonable.

Energy not requested to display, but I could add an energy indicator. Not required. Skip but maybe show. Keep minimal: show the legend with parameters. The task only requires behavior. Let me keep legend.

Let me add a small "energy" readout in legend to demonstrate stability? Not required. I'll keep it minimal but maybe include energy check for my own verification. Let me not clutter; I'll verify in console.

Actually, I can compute and log energy to console for verification. Let me add a console log of energy at start, and maybe periodically. I'll just verify via console during dev.

Let me write reset functionality:
```
function resetState() {
  theta1 = THETA1_0; theta2 = THETA2_0;
  omega1 = 0; omega2 = 0;
  trail.length = 0;
}
```

Pause/resume: toggle `paused`. Button text toggles between "Pause" and "Resume".

Let me make sure that while paused, we don't step physics or add trail points, but trail keeps aging (fades). Actually if trail fades while paused, on a long pause it'll disappear. That's fine and realistic. But maybe keep trail frozen while paused for clarity — the bob is frozen, trail stays. Hmm. Let me keep trail fading only when unpaused to avoid confusion? The phrase "fading trail" describes the visual effect; either is fine. I'll keep aging always (fades naturally). Actually, let me make it so that the trail fade is based on age (real time) always, so it's a true fading trail. When paused, no new points, old fade. Good.

But there's subtlety: while paused, if I don't add points, and the existing points age, the trail shortens/fades — that's expected "fade" behavior. Fine.

Now main loop. Let me use a fixed timestep accumulator:
```
let last = 0;
let acc = 0;
function loop(now) {
  now = now/1000; // seconds
  if (!last) last = now;
  let frame = now - last;
  last = now;
  if (frame > 0.25) frame = 0.25;
  if (!paused) {
    acc += frame;
    while (acc >= DT) {
      rk4Step(DT);
      acc -= DT;
    }
    addTrailPoint();
    cleanTrail(performance.now());
  }
  render();
  requestAnimationFrame(loop);
}
```

Hmm, calling requestAnimationFrame with `loop` receiving DOMHighResTimeStamp in ms. Let me keep ms.

Let me finalize and write the file. Then test via browser tool (screenshot, inspect console). Let me verify energy conservation by logging.

I can't run JS directly except through the browser tool. The browser tool: reload, inspect (shows DOM + console?), screenshot, etc. Let me check what "inspect" returns — likely DOM tree and console logs. I'll use screenshot to see rendering and inspect to check console for errors and my energy log.

Let me add an energy computation and log to console once at start and every second-ish for verification. Actually let me log energy periodically to a flag; to avoid spamming, log every ~1s. I'll do it.

Energy = KE + PE. For double pendulum (point masses, y down with pivot at top, PE = -m g y with y measured downward from pivot... let me compute in sim where pivot is origin and y downward is positive; PE = -m g * y. Let me just compute and it's conserved regardless of constant.

KE = 0.5*m1*v1² + 0.5*m2*v2² where v1 = L1*|ω1|, and v2² = (x2')²+(y2')².
x1' = L1 cos θ1 ω1, y1' = -L1 sin θ1 ω1
x2' = L1 cos θ1 ω1 + L2 cos θ2 ω2
y2' = -L1 sin θ1 ω1 - L2 sin θ2 ω2
v2² = x2'² + y2'²

PE = m1 g y1 + m2 g y2 with y downward positive => PE = m1 g (L1 cos θ1) + m2 g (L1 cos θ1 + L2 cos θ2). Wait that's m g y (y down positive) — but gravitational PE should decrease as bob goes down; with y down positive and PE = -m g y, PE = -m g (height). Let me just compute total and it's conserved. Use PE = -(m1*g*y1 + m2*g*y2) where y measured downward from pivot. Doesn't matter; only differences. I'll compute a consistent value and log; as long as it's ~constant, good.

Let me compute:
y1 = L1 cos θ1 (downward)
y2 = L1 cos θ1 + L2 cos θ2 (downward)
PE = -m1*g*y1 - m2*g*y2  (so bob down = lower PE)
KE as above
E = KE + PE.

I'll log at start and periodically.

Let me write the file and test.

Let me write clean code now.

I think the code is solid. Let me write index.html.

One more: ensure canvas fills .app via CSS width:100%; height:100% and the .app has defined size. I set .app width/height. canvas width/height auto to fill via CSS. Good.

Let me write it.

I realize I should double check the equations sign conventions consistency with my position definition.

θ measured from downward vertical. If θ>0, bob displaced toward +x (right? or left?). Let me define θ from downward vertical, positive to the right (standard). Position with y down:
x = L sin θ, y = L cos θ. At θ=0, x=0,y=L (straight down). At θ=90°, x=L, y=0 (horizontal right). Good.

My derivatives use sin(t1), cos(t1-2t2), etc., consistent with this convention. The standard formula assumes θ from vertical. Sign of gravity term: θ'' should restore toward 0. Let me sanity check θ1'' for single pendulum limit (m2=0 or decoupled): θ1'' ≈ -g/L sin θ1 — restoring. In my formula with m2=0: num1 = -g*(2m1)*sin θ1, denom1 = L1*2m1 => θ1'' = -g/L1 sin θ1. ✓ Good.

For the coupled terms, signs match standard. Good.

Now initial θ1=120°=2.094 rad (leaning up-left if positive is right; 120° means sin positive (right component) but cos negative so y negative i.e., up). 120° from downward = 60° from upward → bob up and to... sin(120°)=0.866 → x positive (right), y=cos(120°)=-0.5 (up). So bob1 is up-and-to-the-right at 120°. Good, high energy. θ2=-10° small dip below bob1's downward (bob2 nearly straight down from bob1). Fine.

Energy should be conserved. Let me verify it's not exploding.

Let me write the file.

I'll also cap the number of trail points (e.g., 300) to avoid runaway memory, plus time-based cleanup. With 60fps and TRAIL_TIME=4s → 240 points. Fine.

Let me write now.

Let me also handle the case where during render the canvas hasn't been laid out yet (W,H=0). I'll call layout on first render or on DOMContentLoaded.

Let me write final code.

For nice rod rendering: use a linear gradient along rod from a darker to lighter, or a metallic look. I'll use a simple approach: stroke with a color and a shadow. Add ctx.shadowColor for a glow. Let me give rods a subtle glow.

Let me make rods thick and slightly glowing. And bobs with radial gradient (shiny sphere).

OK writing now. Let me keep it reasonably concise but high quality.

Let me finalize.

I want to double-check the `cleanTrail` uses performance.now and the trail stored with t=performance.now() — consistent units (ms). Good.

Let me write the file fully.

Also need to make sure requestAnimationFrame loop starts. Attach on DOMContentLoaded or script at end of body. I'll put script at end of body (no defer needed since after elements). Good, I have script after the UI elements. But I reference canvas by id at top of IIFE which runs after body parse — fine.

Let me write.

Let me also add key listeners? Not required. Skip.

Final code below.

Let me write the index.html file with the full double pendulum simulation.

Now let me reload the browser to inspect it and check the console for errors.

There's a console warning about sandboxing — that's a framework thing, not my code. No JS errors. The energy shows 0.149 which seems low. Let me check — wait, the energy display shows "energy: 0.149" but it should be updating with drift percentage. Hmm, the updateEnergy only updates every 400ms. The initial load shows e0. The drift display isn't showing yet because 400ms hasn't passed. The "0.149" initial energy — let me verify that's reasonable.

Wait, let me reconsider the energy value. With θ1=120°, the lower bob reaches high (up). PE = -(m1*y1 + m2*y2)*G. y1 = L1 cos(120°) = 1 * (-0.5) = -0.5 (up). y2 = y1 + L2 cos(-10°) = -0.5 + 1*0.9848 = -0.5 + 0.9848 = 0.4848. 

PE = -(1*(-0.5) + 1*(0.4848))*9.81 = -((-0.5 + 0.4848))*9.81 = -(-0.0152)*9.81 = 0.0152*9.81 ≈ 0.149. 

Yes! PE ≈ 0.149, KE=0 initially. So total energy ≈ 0.149. That's correct. The energy is small because the bobs are nearly balanced (one up half, the other nearly straight down). Makes sense.

Now let me verify the visual output with a screenshot and check motion. Let me take a screenshot and let it run a bit, then inspect the console for the drift.

Let me wait and check the energy drift display and take a screenshot.

The energy drift is only -0.09%, which is excellent — RK4 is conserving energy well. The dom shows the energy updated. The screenshot returned "model does not support images" — that's a limitation of the browser tool, not a problem with my code. Let me check the DOM more thoroughly.

The dom output only shows the button text and legend. Let me inspect the full DOM to make sure the canvas is rendering. Actually the "dom" field seems to return the text content. The canvas would render visually. Since images aren't supported, I can't see the screenshot directly, but the structure is there.

Let me verify behavior more:
1. The energy conservation is great (-0.09% drift) ✓
2. No console errors ✓

Let me inspect the canvas is present and check more DOM. Let me also test the pause/reset by simulating. Actually I can't click via the tool easily... let me check — there's a "click" action. Let me test pause and reset.

Actually, the dom field shows text content of the whole body. The canvas content isn't reflected in text DOM (it's pixel-based). But the structure seems fine.

Let me test the pause/resume and reset buttons via click actions on coordinates. The Pause button is at top-right, Reset next to it. Let me click on the pause button area and see if it toggles to "Resume".

Let me find the coordinates. The app is 95vw, max 980px wide, in a centered body. The UI is at top:14px right:14px. With viewport 1200x800, the app width = min(95vw, 980) = 980px... actually 95vw of 1200 = 1140, capped at 980. So app is 980px wide, centered → left at (1200-980)/2 = 110px. UI right:14px from app → app right edge at 110+980=1090, so UI right at 1090-14=1076 from... the buttons are at top-right. Pause button ~ 16px wide? It's positioned right:14px within app. So pause button x ≈ 1090-14-80 = ~996. y ≈ 14+12 = ~26.

This is approximate. Let me try clicking around there. Actually, let me reconsider — the click tool uses viewport coordinates 1200x800. Let me click the Pause button area.

Actually, let me try clicking the pause button. Let me estimate: pauseBtn is at top:14, right:14 within .app (980 wide starting at x=110). So the button's right edge is at 110+980-14 = 1076 from left. Button width ~90px (padding 9+16+text). So button spans roughly x: 1076-90=986 to 1076, y: 14 to 14+34=48. Center ~ (1030, 31).

Let me click there and check dom for "Resume".

The click didn't seem to toggle the button text to "Resume". The dom still shows "Pause". Maybe my click coordinates were off, or maybe the click landed somewhere else. Let me inspect the DOM more carefully to find the actual button position, or just check by inspecting.

Actually, the "dom" field returned text content which still shows "Pause". The click might have missed. Let me try inspecting the actual DOM structure to get button positions. The inspect action might give more detail. But the output format just gives "dom" as text content. Hmm.

Wait, maybe the click worked but... no, if paused, the button would say "Resume". It still says "Pause". So the click missed the button.

Let me reconsider the layout. The body is flex centered. .app is 95vw max 980px wide, 80vh max 760px tall. With viewport width 1200: 95vw = 1140px, capped to 980. So app is 980px wide, centered horizontally → left offset = (1200-980)/2 = 110px. So app spans x: 110 to 1090.

UI is position:absolute top:14px right:14px within .app. So the UI's right edge aligns 14px from app's right edge (x=1090) → right edge at x=1076. Buttons are in a flex row with gap 10px, starting from right:14. The rightmost button is Pause? No — the HTML order is Pause then Reset, in a flex row. They stack left-to-right: Pause first (leftmost), Reset second (rightmost). Wait, in a flex row they appear in DOM order left-to-right. So Pause is leftmost, Reset is rightmost.

So Reset is at the right edge (right:14 from app), and Pause is to its left.

Reset button right edge at x=1076. Reset width ~ (16+16 padding + "Reset" text ~40px) ≈ 72px. So Reset spans x: 1076-72=1004 to 1076. Pause is to its left with 10px gap: Pause spans x: 1004-10-72=922 to 1004-10=994. Pause center ~ (958, 31).

Hmm, I clicked (1030, 31) which was actually on the Reset button region, not Pause. And Reset doesn't change text. That explains no visible change (well, Reset would reset which it already is).

Let me recompute. Actually wait — I need to be careful. Let me re-examine: flex row, DOM order Pause then Reset. Left-to-right: Pause(left), Reset(right). Right edge of the .ui container is at app-right - 14 = 1090-14 = 1076. The flex row is right-aligned (buttons pushed to right). So Reset (last child) is rightmost at x≈1004-1076. Pause is left of it at x≈922-994.

So to click Pause, I should click around (958, 31). Let me click there. And to click Reset, click (1040, 31).

Let me click the Pause button at ~(958, 31).

No python3. Let me just use bash arithmetic.

Still shows "Pause" not "Resume". Hmm. Maybe the click isn't registering, or my coordinate is still off. The drift is now -0.34%, still good (the sim kept running, meaning pause didn't take effect). 

Wait, the drift went from -0.16% to -0.34%, meaning time passed and the sim continued running (not paused). So the pause click didn't register.

Let me reconsider the button positions. Maybe the viewport isn't 1200 wide, or the app width calculation differs. Let me check — the viewport is 1200×800 per the tool description. But the body might not be exactly 980 wide. Let me think about `max-width:980px` and `width:95vw`. 95vw at 1200 = 1140. So width = min(1140, 980) = 980. Centered → left 110. That seems right.

But maybe the buttons are smaller. "Pause" text is short, button width ≈ 16+8+16 = 40px + padding. Actually the button padding is "9px 16px". Text "Pause" at 14px font ≈ width ~ 8px*5 = 40px? Plus padding 16*2 = 32 → total ~72px. "Reset" similar (~72px). Let me recompute with 72px buttons and gap 10.

Reset right edge at 1076 (right:14 means the .ui container right edge is at 1076, but buttons... wait, right:14 is on .ui which contains the flex row. The flex row fills .ui. Rightmost button (Reset) right edge = .ui right edge = 1076? Actually .ui doesn't have explicit width, so it shrinks to content, and right:14 positions its right edge. So Reset right edge = 1076. Reset left = 1076-72 = 1004. Pause right = 1004-10 = 994. Pause left = 994-72=922. Pause center = (922+994)/2=958. That's what I clicked (957). y: top:14, button height ~ 9+14+9=32px (padding vertical 9*2 + font 14 ≈ 32). Plus maybe border. So button spans y 14..46, center ~30. I clicked y=31. Should be in range.

Hmm. So why didn't it register? Maybe the click coordinates in the tool are relative to something else, or the viewport size is different. Or maybe clicking works but the event handler has an issue.

Wait — maybe the issue is that the click DID register as paused=true, button text became "Resume", but then... no, the dom still shows "Pause". 

Alternatively, maybe the click is being applied but the iframe viewport coordinates differ. Let me try a different approach — maybe inspect the actual rendered button location. But inspect only returns text dom.

Let me reconsider: perhaps the viewport the browser uses is the iframe's own viewport, and 95vw refers to that iframe viewport which is 1200×800. So app left=110. Hmm.

Actually, wait. Let me re-read: "Coordinates use a 1200×800 viewport." So the viewport is 1200 wide. The iframe is sandboxed at 1200×800. So my calculation should hold.

Let me try clicking slightly differently — maybe the buttons are positioned differently, or maybe I should click and check console. Let me try clicking at a few candidate spots. Let me try (960, 30) again — maybe it's a timing thing. Or maybe the click tool requires the element to be clickable and there's an overlay.

Actually — the .ui div is on top (z-index? not set, but it's positioned absolute and after canvas in DOM, so it's above canvas). The buttons should be clickable. 

Hmm, let me reconsider whether the body's flex centering plus the .app sizing actually produces 980px width. Actually `width: 95vw` with `max-width: 980px`. If the iframe viewport is 1200, 95vw=1140, min with 980 → 980. Centered by flex `justify-content:center`. So left gap = (1200-980)/2 = 110. OK.

But wait, is the iframe viewport exactly 1200? The tool says coordinates use 1200×800. So yes.

Let me try clicking Reset at (1040, 31) to confirm clicks work at all, and then Pause at left. Actually, let me just try clicking Pause again at a slightly different spot, and also try the motion check differently. 

Actually, maybe the problem: my click coordinate y=31 — but the button might be lower. Let me reconsider button top: 14px from .app top. .app top: where is .app vertically? Body is flex centered vertically too (align-items:center). .app height = 80vh = 640px, max 760. At 800vh → 80vh=640, so app height 640. Centered → top gap = (800-640)/2 = 80. So .app top is at y=80, not 0! 

So the UI's "top:14px" is relative to .app top = y 80. So Pause button top = 80+14 = 94. Button spans y 94 to 126. Center y ~ 110.

I clicked y=31 which is in the upper empty area, missing the button entirely! That's the bug in my testing, not the code.

Let me click at (957, 110) for Pause and (1040, 110) for Reset.

Let me verify app vertical position: body height 800, app height = 80vh. 80vh of 800 = 640. (800-640)/2=80. Yes app top at 80.

So UI top = 80+14 = 94. Button height ~ 32 → spans 94..126. Center y=110.

Let me click Pause at (957, 110).

Now the Pause button toggled to "Resume" (paused=true). The dom shows "Resume". The energy drift is -0.45% which accumulated before pause. Now the sim should be paused — energy should be frozen.

Let me click Resume (same spot) to unpause, then test Reset at (1040, 110).

Actually, let me verify pause froze the motion: click somewhere to confirm. The energy display updates only when unpaused. Let me click "Resume" at (957,110) to resume, then click "Reset" at (1040,110).

Actually, to verify pause works: I paused, and the energy drift stopped changing (was -0.45% and would stay if paused). Let me now resume and then reset.

Let me click Reset at (1040, 110). But first, let me resume so the reset test is clean. Actually reset works regardless of paused state. Let me just test reset: click Reset, check that button shows "Pause" again (reset sets paused=false) and energy back to 0.149 with cleared trail.

Let me click Reset at (1040, 110).

Wait, currently paused (Resume button shown). Let me click it to resume first, then click reset. Actually, let me just click Reset directly — reset sets paused=false, text to "Pause". The dom should then show "Pause".

Let me click Reset at (1040, 110).

Reset works: button shows "Pause" again, energy back to 0.149 (initial). 

Now let me verify the motion/visual. I can't get a screenshot (images not supported). But I can sample the positions via the console by... hmm, I can't run arbitrary JS. 

Let me think about how to verify the coupled motion and trail visually. The screenshot doesn't work. But the dom inspection shows text. The canvas renders pixels but the tool can't capture them as images.

However, I can reason about correctness:
- Energy drift is small (-0.45% after several seconds of chaotic motion) → RK4 is stable and accurate ✓
- No console errors ✓
- The starting pose: θ1=120° (bob1 up-right), θ2=-10° (bob2 nearly straight down from bob1's downward direction). ✓
- Pause/Resume toggles ✓
- Reset restores initial state and clears trail ✓

For visual verification, I can't see the screenshot. But let me check: does the pendulum render properly? The canvas exists. Let me verify there are no issues by inspecting the DOM structure more. 

Actually, I want to verify the visual quality. Since images aren't supported, let me at least confirm the canvas is properly sized and being drawn. Let me check by inspecting. But the inspect output is just text content.

Hmm. The task says "Run the application in the browser and inspect the initial output and console." I've done that. The console has only the sandbox warning (harness-level, not my code). The dom shows the structure.

Let me reason: the energy display updating with drift over time proves:
1. Physics is running (energy changes as motion happens — wait, energy is conserved, so it shouldn't change much; the drift is the tiny RK4 error). The drift percentage changes over time because the sim runs more. That confirms the loop runs and rk4Step executes.
2. The initial energy 0.149 matches my hand calculation. ✓

The fact that energy is conserved to within 0.45% over several seconds of chaotic double-pendulum motion confirms the integration is stable and accurate — this is a strong verification.

For the visual: I'm confident the rendering code is correct. Let me just double-check a couple of potential issues:

1. In `render()`, I check `if (needLayout) layout();`. The layout sets csw, csh, scale, pivotX, pivotY. Initially needLayout=true. On first render, layout() runs. Good. But I also call `addTrailPoint()` before the first requestAnimationFrame — at that point sX/sY use positions and pivotX/scale which are 0 until layout! The first addTrailPoint pushes a trail point with sim coords (x2,y2) but sX/sY would be wrong until layout. However, cleanTrail will remove old points, and the first trail point at (x2,y2) with pivotX=0,scale=0... actually addTrailPoint just stores sim coords {x,y,t}, not screen coords. The screen conversion happens in drawTrail via sX/sY at render time. So as long as layout ran before render, sX/sY are correct. Since needLayout triggers layout() at top of render() before drawTrail(), it's fine. The first trail point gets drawn correctly after layout. But actually the very first point is added before any layout — it's stored in sim space, fine; rendered after layout sets correct scale. Good.

2. The lower bob initial position: θ1=120°, θ2=-10°. x1=sin(120°)=0.866, y1=cos(120°)=-0.5. x2=0.866+sin(-10°)=0.866-0.1736=0.6924, y2=-0.5+cos(-10°)=-0.5+0.9848=0.4848. So bob2 is at sim (0.69, 0.48) — to the right and slightly down from pivot. bob1 at (0.866,-0.5) — up and to the right. So bob1 is high up, bob2 hangs below-ish. The pendulum extends from pivot(0,0) up to bob1 (y=-0.5, i.e., 0.5 up) and down to bob2 (y=0.48). Total vertical extent from y=-0.5 to y=0.48 = ~1 unit, plus the rods. Max reach 2 units. With scale computed to fit 2.4 units in min(csw*0.95,csh*0.90)/2.4... 

3. Scale cap at 300. If csw ~980, scale = min(980*0.95, 640*0.90)/2.4 = min(931, 576)/2.4 = 576/2.4 = 240. Under 300 cap. Good. So scale=240, extent 2 units = 480px. pivotY = 640*0.22=140. bob1 at y=-0.5*240=-120 → screen y=140-120=20 (near top, within canvas). bob2 at y=0.48*240=115 → screen y=140+115=255. Good, visible. Max downward reach y=2*240=480 → 140+480=620 < 640. Good, stays visible. Max upward y=-... bob1 up to -2 units → 140-480=-340 (off top) — but that's only if it goes fully up which won't happen from this initial condition with this energy. Anyway, the requirement "keep pendulum visible" — the initial pose and likely motion stays in view. Good.

Actually the requirement: "Keep both rod lengths constant and the pendulum visible." The pendulum could potentially swing widely in chaotic motion. With energy 0.149 (relatively low), the motion might be bounded. Let me check max energy vs potential. The total energy is 0.149. For the pendulum to flip (bob go over the top, y1=-2), it would need PE = -m*g*(-2)... PE = -(m1*y1+m2*y2)*g. At the top flip (both up), y1=-2, y2=-2 (if both rods up) → PE = -((1)(-2)+(1)(-2))*9.81 = -(-4)*9.81=39.24. Way more than 0.149. So it can't flip. The motion is bounded oscillation, mostly. Actually with θ1=120° it might swing but bounded. The max height bob1 reaches: energy 0.149, when KE=0. Initial PE=0.149. So motion stays within the region where PE ≤ 0.149. At θ1=120°, bob1 y1=-0.5 (up 0.5). PE contribution... the point is the motion is bounded and stays roughly within ±120° ish, possibly a bit more but bounded. It should stay visible. Good.

Actually, double pendulum can be chaotic and energy transfers; bob2 could potentially reach up to its own top. But total energy 0.149 is quite low (close to the equilibrium where bobs nearly balance). Wait, 0.149 is barely positive. The equilibrium hanging straight down (θ1=θ2=0): y1=1, y2=2 → PE = -((1)(1)+(1)(2))*9.81 = -29.43. So energy 0.149 means the system is ~29.6 above the minimum. Hmm wait that's a lot actually. Minimum PE = -29.43 (both hanging down). Total energy = 0.149 (since initial PE=0.149, KE=0). So the system has 0.149 - (-29.43) = 29.58 units of "excess" energy above minimum?? 

Wait that doesn't seem right. Let me recompute initial PE. θ1=120°, θ2=-10°. 
y1 = L1 cos θ1 = 1 * cos(120°) = -0.5
y2 = y1 + L2 cos θ2 = -0.5 + 1*cos(-10°) = -0.5 + 0.9848 = 0.4848
PE = -(m1*y1 + m2*y2)*G = -(1*(-0.5) + 1*(0.4848))*9.81 = -(-0.0152)*9.81 = 0.149

Yes PE=0.149. The minimum PE (both hanging down, θ1=θ2=0): y1=1, y2=2 → PE = -(1+2)*9.81 = -29.43. So energy 0.149 is 29.58 above the minimum PE. That means there's enough energy for the system to do a LOT — potentially flip over! 

Wait, that means the system is high-energy and chaotic. With 29.58 excess energy, bob1 can definitely reach the top (needs PE at top: θ1=180°, y1=-1, and θ2... at θ1=180° θ2=0: y1=-1, y2=-1+1=0 → PE = -((-1)+0)*9.81 = 9.81). 9.81 > 0.149? No, 9.81 < ... wait we compare total energy. To flip bob1 over the top (θ1=180) with bob2 hanging: needs PE=9.81. Total energy 0.149 < 9.81, so it CANNOT flip over the top going straight up because that requires PE=9.81 > 0.149. 

Hmm wait, I need to be careful. Energy is conserved at 0.149. PE at any configuration must be ≤ 0.149 (since KE≥0) for that config to be reachable. The minimum PE is -29.43 (hanging down). Configurations with PE ≤ 0.149 are reachable (with KE = 0.149 - PE ≥ 0).

For bob1 to be at the top (θ1=180°, y1=-1): even with bob2 also up (y2=-2): PE = -((-1)+(-2))*9.81 = -(-3)*9.81 = 29.43 > 0.149. Not reachable. So bob1 never reaches the top. Max θ1 reach: at θ2 chosen to minimize PE for given θ1... Actually the reachable region: we need PE(θ1,θ2) ≤ 0.149. 

PE = -((cos θ1) + (cos θ1 + cos θ2))*G = -G*(2 cos θ1 + cos θ2)... wait m1=m2=1: PE = -G*(y1 + y2) = -G*(cos θ1 + cos θ1 + cos θ2) = -G*(2 cos θ1 + cos θ2).

PE ≤ 0.149 → -9.81*(2 cos θ1 + cos θ2) ≤ 0.149 → 2 cos θ1 + cos θ2 ≥ -0.149/9.81 = -0.0152 → 2 cos θ1 + cos θ2 ≥ -0.0152.

Max θ1: set cos θ2=1 (θ2=0) → 2 cos θ1 + 1 ≥ -0.0152 → cos θ1 ≥ -0.5076 → θ1 ≤ arccos(-0.5076) = 120.5°. So θ1 can reach about 120.5° (just past initial 120°). So the motion is bounded near the initial high point — bob1 oscillates but can't flip. Max |θ1| ≈ 120°. 

So vertical extent: bob1 reaches y1 = cos(120.5°) ≈ -0.507 (up 0.507). bob2 max up: when both up-ish. y2 = cos θ1 + cos θ2. With constraint 2cos θ1+cos θ2 ≥ -0.0152. Max y2 (downward positive, most down) is large. Max upward reach of bob2: minimize y2 = cosθ1+cosθ2 subject to 2cosθ1+cosθ2 ≥ -0.0152. Set cosθ2 minimum. cosθ2 ≥ -0.0152 - 2cosθ1. To minimize y2=cosθ1+cosθ2, set cosθ2 = -0.0152-2cosθ1 → y2 = cosθ1 -0.0152 -2cosθ1 = -cosθ1 -0.0152. To make y2 most negative (up), maximize cosθ1 → cosθ1=1 (θ1=0): y2 = -1-0.0152 = -1.015. So bob2 can reach up to y2=-1.015 (up ~1 unit from pivot). So total vertical reach from pivot: bob2 up to -1.015 (up 1 unit) and the rods... actually bob2 is at distance 2 from pivot max. The lowest bob2 reaches: when both straight down, y2=2. But energy 0.149 < PE at straight down (-29.43)? No: PE at straight down = -29.43 which is < 0.149, so straight down IS reachable (lots of KE). So bob2 swings down to y2=2 (straight down, 2 units below pivot). So full vertical extent 2 units down and ~1 unit up. With pivotY=140 and scale=240: max down = 140+2*240=620 (in canvas, height 640 ✓ barely). Max up = 140-1*240= -100 (off top!). 

Hmm, bob2 reaching up to y=-1 (up 1 unit from pivot) would put it at screen y = 140-240 = -100, off the top of the canvas! That violates "keep pendulum visible."

But does bob2 actually reach y=-1? That requires θ1=0, θ2=180° (bob2 straight up while bob1 straight down). That's a specific high-LE exchange. With low total energy 0.149, is θ2=180° reachable? At θ1=0, θ2=180°: cosθ1=1, cosθ2=-1 → 2(1)+(-1)=1 ≥ -0.0152 ✓. PE = -9.81*1 = -9.81 ≤ 0.149 ✓. So yes reachable, with KE = 0.149-(-9.81)=9.96. So bob2 CAN shoot straight up. That means the lower bob reaches up to screen y = pivotY + scale*(-1.015) = 140 - 244 = -104, off the top!

So with these parameters, the pendulum can go off the top of the canvas. That violates "the pendulum visible."

I need to ensure the pendulum stays visible. Options:
1. Lower the pivot point (move pivotY down) so the upward reach fits. If bob2 reaches up to -1 unit (and bob1 up to -0.507 from pivot), the max upward extent from pivot is about 1.0 unit (bob2 at y=-1.015). Wait, bob2 at y2=-1.015 means 1.015 units ABOVE pivot. And max downward: bob2 at y=2 (2 units below pivot). So total extent 3.015 units. To fit in canvas height 640 with margin: scale = 640*0.90/3.015 ≈ 191. pivotY needs to be low enough that upward (-1.015*191 = -194) stays visible: pivotY - 194 ≥ some margin → pivotY ≥ 194+margin. And downward 2*191=382: pivotY+382 ≤ 640-margin → pivotY ≤ 640-382-margin. 

If pivotY = 194+30 = 224 (top margin 30), then bottom = 224+382 = 606 ≤ 640-30=610 ✓. So with scale 191, pivotY 224, extent fits with ~30px margin. But this is getting complicated and the scale would be smaller.

Actually, wait — does the pendulum really reach y2=-1 (bob2 straight up)? That requires θ2=180° which is an extreme. With initial energy 0.149 and the chaotic transfer, it's theoretically reachable but maybe not in a typical short playback. But to be safe and satisfy "keep pendulum visible," I should size the canvas so the full possible extent (2L downward + some upward) fits, OR place pivot low enough.

Actually, the maximum distance from pivot for ANY bob is 2L (when both rods align, bob2 is 2L away). The bob can be in any direction within a circle of radius 2L around the pivot. So to always keep it visible, the canvas must contain a circle of radius 2L=2 around the pivot with margin. So the pivot should be at the center of the canvas (or at least 2L from all edges with margin).

So: scale based on containing a circle of radius 2 (the full reach). pivotX = csw/2, pivotY = csh/2 (centered). scale = min(csw, csh)*0.45 / 2 (radius) → with 10% margin each side. Actually circle diameter = 4 units. scale = min(csw,csh)*0.9/4 = min*0.225. For 980×640: min=640, scale=144. Hmm smaller. Or use more of the canvas: scale = min(csw*0.9, csh*0.9)/4. 

But centering the pivot makes it less visually centered (pendulum hangs from middle-top usually). The requirement says "Draw a fixed pivot" — doesn't specify position. A centered pivot with full reach visible is the safest interpretation of "keep pendulum visible." But it makes the pendulum appear in the middle with equal room above and below.

Alternatively, place pivot higher (top area) but ensure the full downward reach (2L down) fits and accept that upward excursions might clip — but that risks violating "visible."

Hmm, but realistically, will bob2 actually go straight up? With energy 0.149 and initial θ1=120°, θ2=-10°, the system is chaotic. Energy will slosh. The lower bob reaching straight up (θ2=180°, θ1=0°) is possible but the probability and whether it happens depends on the chaotic trajectory. 

Actually, let me reconsider the energy. Wait, I think I need to recompute whether 0.149 really allows θ2=180°. Let me reconsider: total E = 0.149 (PE_initial, since KE=0). For the config θ1=0, θ2=180°: PE = -9.81*(2cos0+cos180) = -9.81*(2-1) = -9.81. E=0.149 ≥ PE=-9.81 ✓ reachable. KE = 0.149-(-9.81) = 9.96 > 0 ✓.

So yes it's reachable. But more carefully: is there a continuous path of allowed configurations from initial to that config? In phase space the energy surface is connected for this energy (below the first flip threshold), and typically yes chaotic. It might take a while but could happen.

To be SAFE and satisfy "keep pendulum visible" robustly, I'll center the pivot and fit the full 2L reach circle. Actually, let me reconsider — maybe a better approach: place pivot at top-center-ish but size canvas to fit the FULL extent including upward reach. The upward reach is at most 2L above pivot (if bob2 goes straight up, 2L above pivot). The downward reach is 2L below. So the vertical extent is 4L total if we allow full circle. To allow full swing in all directions, pivot must be 2L from every edge.

I'll center the pivot and fit a 2L-radius region. Let me set:
- scale = min(csw, csh) * 0.45 / (2*L) ... wait the radius to fit is 2L (max distance). To have margin, scale = min(csw,csh)*0.9 / (2 * 2L) = min*0.9/(4L). With L=1: scale = min(csw,csh)*0.225.

Hmm that gives scale ~144 for 640 height. Bob radius R1=0.095*144=13.7, R2=0.075*144=10.8. Fine.

pivotX = csw/2, pivotY = csh/2.

But then the pendulum starts (θ1=120°) at bob1 up-right and hangs... it'll look centered. That's acceptable and robustly keeps everything visible.

Actually, wait. Let me reconsider. Maybe I'm overcomplicating. Let me reconsider whether bob2 really can reach 2L above pivot. For bob2 to be at 2L directly above pivot, need θ1=θ2=180° (both rods up). PE = -9.81*(2cos180+cos180) = -9.81*(-2-1) = -9.81*(-3)=29.43. E=0.149 < 29.43, NOT reachable. So bob2 can't go fully above pivot by 2L.

The reachable upward reach of bob2: max (pivot_y - bob2_y) where bob2 is above pivot = max(-y2). y2 = cosθ1+cosθ2. We want to minimize y2 (most negative) subject to PE ≤ 0.149 i.e. 2cosθ1+cosθ2 ≥ -0.0152. 
y2 = cosθ1 + cosθ2, with cosθ2 = -0.0152 - 2cosθ1 (boundary, KE=0) → y2 = cosθ1 -0.0152 -2cosθ1 = -cosθ1 -0.0152. Minimize over cosθ1∈[-1,1]: y2 minimized when cosθ1=1 → y2 = -1-0.0152 = -1.0152. So bob2 reaches at most 1.015 above pivot (y2=-1.015). Not 2L. Good — so upward reach is about L+ε, not 2L.

Downward reach of bob2: maximize y2 = cosθ1+cosθ2 subject to 2cosθ1+cosθ2 ≥ -0.0152 (always satisfied for cos values) — no upper bound from energy on the downward side (PE gets more negative, KE increases). Max y2 = cosθ1+cosθ2 with both =1 → y2=2 (straight down). Reachable? PE=-9.81*3=-29.43 < 0.149 ✓ with KE=29.58. Yes bob2 reaches 2L below pivot.

So: upward reach ~1.015L, downward reach ~2L. Vertical extent from highest to lowest bob point = 1.015 + 2 = 3.015L ≈ 3.015 units. 

So if I place pivot at top with the downward (2L) fitting and upward (1.015L) also fitting: pivotY must be ≥ 1.015*scale + margin (so upward doesn't clip top) AND pivotY + 2*scale ≤ csh - margin (downward fits bottom).

With scale: min height available = csh - 2*margin. scale*3.015 ≤ csh-2*margin. For csh=640, margin=40: scale ≤ 600/3.015 = 199. pivotY = 1.015*199 + 40 = 202+40 = 242 from top. Downward: 242+2*199 = 640 ✓ exactly (640 = 242+398=640, with margin bottom... 640-640=0, need margin). Let me use margin=50: scale ≤ 590/3.015=195.7→195. pivotY = 1.015*195+50 = 198+50=248. Bottom = 248+390=638 < 640-50=590? No 638 > 590. Wait I need to recompute. csh-margins_top-margins_bottom = 640-50-50=540. scale*3.015 ≤ 540 → scale ≤ 179.2. pivotY = 50 (top margin) + ... pivotY such that upward reach (1.015*scale) above pivot: pivotY - 1.015*scale ≥ 50 → pivotY ≥ 50 + 1.015*179 = 50+182 = 232. And downward: pivotY + 2*scale ≤ 640-50=590 → pivotY ≤ 590-358 = 232. So pivotY=232, scale=179. Works! 

So with pivot near upper-middle (pivotY ~ 232 for 640 height, i.e., 36% from top), scale ~179, both upward and downward reach fit with 50px margins.

This is more complex than centering. The simplest robust choice: center pivot, fit 2.015L radius (half extent = max(2L down, 1.015L up) = 2L down is the constraint for centering). If centered, need 2L (down) + 1.015L (up) ≤ in radius terms... centered means pivot at center, need pivot to be 2L from bottom (downward reach) and 1.015L from top (upward reach). Since 2L > 1.015L, the downward is the constraint: need scale*2L ≤ csh/2 - margin → scale ≤ (csh/2 - margin)/(2L). With csh=640, margin=40: (320-40)/2 = 140. pivotX=csw/2, pivotY=csh/2=320. Upward reach 1.015*140=142 ≤ 320-40=280 ✓. 

Centered is simplest and clearly keeps everything visible. Let me go with centered pivot. scale = min(csw, csh)/2 * 0.88 / (2) → i.e., use 88% of half-extent. Let me compute: radius needed = 2L (downward is max). half_canvas = min(csw,csh)/2. scale = half_canvas * 0.9 / (2*L) = min(csw,csh)*0.45/(2L). For 640: 640*0.45/2=144. 

Hmm, but with centered pivot and the pendulum hanging, the initial pose (bob1 up at 120°) places bob1 above center and bob2 below — looks fine, symmetric-ish. Good.

But actually, visually a pendulum hanging from the top-center is more conventional and appealing. But the safety of "visible" matters more here. The centered approach guarantees visibility. But it wastes vertical space (pendulum starts in middle, equal space above/below). 

Given the trade-off and the explicit requirement "keep the pendulum visible," I'll prioritize safety. However, centered means a lot of empty space above where bob goes (never reaches top). 

Compromise: place pivot at ~30% from top, compute scale to fit both upward (1.05L) and downward (2L) reaches with small margins. This looks good (pendulum hangs in lower 70%, like a real setup) AND stays visible.

Let me implement the robust layout:
```
function layout() {
  csw = canvas.clientWidth; csh = canvas.clientHeight;
  const dpr = ...
  canvas.width = csw*dpr; canvas.height = csh*dpr;
  // max upward reach above pivot ~ 1.05*L_total (L_total=2L), downward 2L
  const upReach = 1.06 * (L1+L2);
  const dnReach = (L1+L2);
  // also horizontal reach up to L1+L2 = 2L
  const lrReach = L1+L2;
  // fit within canvas with margins
  const margin = Math.min(csw, csh) * 0.06;
  const availW = csw - 2*margin;
  const availH = csh - 2*margin; // we'll anchor pivot lower
  // scale constrained by horizontal extent (2L) and vertical (up+down = 3.06L)
  const scaleW = availW / (2*lrReach);
  const scaleH = availH / (upReach + dnReach); // 3.06L
  scale = Math.min(scaleW, scaleH, 300);
  // pivot horizontally centered, vertically so that downward reach fits bottom with margin
  // pivotY + dnReach*scale <= csh - margin  => pivotY <= csh - margin - dnReach*scale
  // also pivotY - upReach*scale >= margin => pivotY >= margin + upReach*scale
  pivotX = csw/2;
  pivotY = csh - margin - dnReach*scale; // anchor to fit bottom (downward is bigger)
  // check top: pivotY - upReach*scale = csh - margin - dnReach*scale - upReach*scale = csh - margin - (dn+up)*scale
  //   = csh - margin - 3.06*scale. Need >= margin: csh - 2*margin - 3.06*scale >=0, which is the scaleH constraint. OK consistent.
}
```
With scaleH = availH/(up+dn)L = availH/3.06L. availH = csh-2margin. So (dn+up)*scale = 3.06*scale = availH = csh-2margin. Then top check: pivotY - up*scale = csh-margin-dn*scale - up*scale = csh-margin - (dn+up)*scale = csh-margin-(csh-2margin)= margin. ✓ Exactly fits top with margin. Good, consistent.

Let me recompute numbers for 980×640, margin = 0.06*min(980,640)=0.06*640=38.4. availW=980-76.8=903.2, scaleW=903.2/4=225.8. availH=640-76.8=563.2, scaleH=563.2/(3.06)=184.1. scale=min(225.8,184.1,300)=184.1. pivotY = 640-38.4 - 2*184.1 = 640-38.4-368.2 = 233.4. 

So pivot at y≈233 (top margin ~38, bob reaches up to 233-1.06*184=233-195=38 ✓ margin, down to 233+368=601, bottom margin 640-601=39 ✓). 

Downward reach 2*184=368, bob radius etc. Good. This fits everything with ~38px margins and uses most of the canvas. The pendulum hangs from upper-third. 

This is robust. Let me update the layout function.

Actually, let me simplify: I was using extent = 2L1+0.4 before and pivotY = csh*0.22. That didn't account for upward reach. Let me replace with the robust version.

Let me also reconsider: is upReach really 1.06*(L1+L2)? The max upward position of the lowest bob is y2 = -1.0152 (computed above), so upReach = 1.0152*max... but L1+L2=2. y2=-1.015 → upReach=1.015. Using 1.06*(L1+L2)=1.06*2=2.12?? No! That's wrong. upReach is 1.015 units (≈0.5075*(L1+L2)). I conflated.

Let me recompute. upReach (max distance above pivot for lower bob) = 1.0152 units ≈ 1.015*L... but L here is rod length =1, and L1+L2=2. So upReach ≈ 1.015 = 0.5075*(L1+L2). And dnReach (max below) = 2.0 = (L1+L2).

So upReach = 1.015 (≈0.5075 of total length). Let me just use the actual computed bound. To be safe, use upReach = 1.1 (slightly more than 1.015) and dnReach = 2.0 (= L1+L2). Actually the absolute maximum any mass can be from pivot is L1+L2=2 (when both rods same direction). The upper mass bob1 can be at most L1=1 above pivot? bob1 reach up: y1=cosθ1, min y1=-1 (θ1=180°, bob1 straight up). PE at θ1=180°: reachable? At θ1=180, θ2=0: 2cos180+cos0 = -2+1=-1 ≥ -0.0152 ✓. So bob1 can reach y1=-1 (straight up, 1 unit above pivot). So upReach for any mass = 1.0 (bob1) or 1.015 (bob2). So upReach = 1.015 ≈ 1.02.

So vertical total extent = 1.02 (up) + 2.0 (down) = 3.02 ≈ 3.02 units. Horizontal reach = 2.0 (L1+L2). 

Let me set:
- lrReach = L1+L2 = 2.0 (horizontal max)
- upReach = 1.02 (I'll compute as ~1.02; but to be safe and not over-pad, use the actual max which is bob2 at -1.0152, so 1.0152; round to 1.02)
- dnReach = L1+L2 = 2.0

Actually, simpler and safe: the whole pendulum fits in a circle of radius (L1+L2)=2 centered at pivot IF it could go all directions — but it can't go 2L up. The bounding box: x ∈ [-2,2], y ∈ [-1.02, 2.0]. To be fully safe with minimal assumptions, use a box x∈[-2,2] (width 4), y∈[-1.02, 2.0] (height 3.02).

Let me just use:
- width needed = 2*(L1+L2) = 4 (horizontal extent, full swing to both sides) — bob2 can reach x2 up to... x2 = sinθ1+sinθ2. Max |x2|: could be up to 2 (both horizontal same direction). Is θ1=90,θ2=90 reachable? 2cos90+cos90=0 ≥ -0.0152 ✓, PE=-9.81*0=0 ≤0.149 ✓. So yes bob2 reaches x2=2 (horizontal). So horizontal extent ±2 → width 4. down. 
- height needed = upReach(1.02) + dnReach(2.0) = 3.02.

So:
scaleW = availW / 4
scaleH = availH / 3.02
scale = min(scaleW, scaleH, 300)

With 980×640, margin 38.4: availW=903.2→scaleW=225.8; availH=563.2→scaleH=186.7; scale=186.7. 
pivotX = csw/2 = 490. pivotY: anchored so top margin and bottom margin fit. pivotY such that pivotY - upReach*scale = margin and pivotY + dnReach*scale = csh - margin. With upReach*scale=1.02*186.7=190.4, dnReach*scale=2*186.7=373.4. Check: 190.4+373.4=563.8 ≈ availH 563.2 ✓ (rounding). pivotY = margin + upReach*scale = 38.4+190.4=228.8. Bottom: 228.8+373.4=602.2, csh-602.2=37.8≈margin ✓.

Good. Let me implement with these exact bounds. I'll set upReach = 1.02 (safe). Actually to be safe against the exact reachable bound (1.0152), 1.02 has tiny margin; fine. But what if I slightly underestimate and a freak trajectory clips? The bound 1.02 > 1.0152 gives margin. Good.

Hmm, but actually is 1.0152 the true maximum upward? I derived it assuming KE≥0 and PE≤E. The config with y2 minimal is θ1=0, θ2=180° giving y2 = cos0+cos180 = 1-1 = 0?? Wait, reccompute. y2 = cosθ1 + cosθ2. For θ1=0, θ2=180°: cos0=1, cos180=-1 → y2 = 1 + (-1) = 0. That's y2=0, not -1.015! I made an error.

Let me redo. We want to MINIMIZE y2 = cosθ1 + cosθ2 subject to 2cosθ1 + cosθ2 ≥ -0.0152 (= E/G with sign... let me redo from PE ≤ E).

PE = -G(2cosθ1 + cosθ2). Constraint PE ≤ E = 0.149 → -9.81(2cosθ1+cosθ2) ≤ 0.149 → 2cosθ1 + cosθ2 ≥ -0.149/9.81 = -0.01519.

Minimize y2 = cosθ1 + cosθ2. Let u=cosθ1∈[-1,1], v=cosθ2∈[-1,1]. Minimize u+v s.t. 2u+v ≥ -0.01519.

The constraint: v ≥ -0.01519 - 2u. And v ≥ -1 (lower bound). So v_min = max(-1, -0.01519-2u). y2 = u + v_min.

For the boundary v = -0.01519-2u to be ≥ -1: -0.01519-2u ≥ -1 → 2u ≤ 0.9848 → u ≤ 0.4924. So for u ≤ 0.4924, v_min = -0.01519-2u, y2 = u -0.01519 -2u = -u -0.01519. Minimize: increase u → y2 decreases. At u=0.4924: y2 = -0.4924-0.01519 = -0.5076. At u>0.4924, v_min=-1, y2=u-1, minimized at u=0.4924: y2=-0.5076 (consistent), and increases after. So minimum y2 = -0.5076 at u=0.4924 (θ1≈60.5°), v=-1 (θ2=180°).

So bob2's maximum upward reach is y2=-0.5076, i.e., 0.5076 units ABOVE pivot. NOT 1.015. I made an arithmetic error before (I wrongly substituted). 

Let me double check: at u=cosθ1=0.4924 (θ1=arccos(0.4924)=60.5°), v=cosθ2=-1 (θ2=180°). Constraint: 2(0.4924)+(-1)=0.9848-1=-0.0152 ≥ -0.0152 ✓ (boundary, KE=0). y2=u+v=0.4924-1=-0.5076. ✓. So bob2 reaches up to 0.5076 above pivot. 

So upReach = 0.5076 ≈ 0.51 units above pivot. Much less than I thought. And bob1's up reach: y1=cosθ1, min at θ1=180° (u=-1): y1=-1. Constraint at u=-1: 2(-1)+v≥-0.0152 → v≥1.9848, impossible (v≤1). So θ1=180° NOT reachable (consistent, can't flip). Max upReach of bob1: y1=cosθ1 with constraint 2u+v≥-0.0152 and v can be anything in [-1,1]. To minimize y1=u (most negative u): set v=1 (max) to satisfy constraint: 2u+1≥-0.0152 → u≥-0.5076. So u_min=-0.5076 → θ1=arccos(-0.5076)=120.5°, y1=-0.5076. So bob1 reaches up to 0.5076 above pivot. Same as bob2. Makes sense by symmetry of the bound.

So BOTH bobs reach at most 0.5076 above pivot. And downward: bob2 to y2=2 (straight down). bob1 to y1=2 (when θ1=0, but θ2=... y1=cosθ1=2 impossible; y1 max=1, θ1=0). bob2 straight down y2=2 reachable. So dnReach=2.

So total vertical extent = 0.5076 (up) + 2.0 (down) = 2.5076 ≈ 2.51 units. Horizontal = ±2 → width 4.

So with the correct bound, the upward reach is only ~0.51, similar to the initial bob1 position (which started at y1=-0.5). So the pendulum stays mostly in the lower portion, and the initial placement pivotY=csh*0.22 was actually almost fine! The issue was only potential upward excursions to y=-0.51 (bob2 at -0.5076). With pivotY=140 (csh*0.22=140 for height 640), upReach 0.5076*scale. If scale=240, upReach screen = 0.5076*240=122, top of bob = 140-122=18 > 0 ✓ visible with margin! And initial bob1 at y=-0.5 → 140-120=20, visible. 

Wait, so my ORIGINAL layout (extent=2L+0.4, pivotY=csh*0.22) actually works because the upward reach is only ~0.51, not 1.0! Let me re-examine. Original: extent=2*L1+0.4=2.4, scale=min(csw*0.95,csh*0.92)/2.4. For 640 height: min(931, 589)/2.4 = 589/2.4=245. cap 300 → 245. pivotY=640*0.22=140.8. Up reach 0.51*245=125 → top = 140.8-125=15.8 >0 ✓. Down reach 2*245=490 → bottom=140.8+490=630.8 < 640 ✓. 

So actually the original layout keeps it visible! My panic about up to 2L-up was based on an arithmetic error. The real upward bound is ~0.51L. 

But wait — is 0.5076 the true reachable maximum, assuming the system can actually explore that configuration? The energy surface might not connect to that exact point, but it's the theoretical bound; actual motion stays within. So upReach ≤ 0.5076. With margin it's safe.

But hold on, I should double-check the downward reach doesn't exceed 2L. bob2 straight down is y2=2 (θ1=θ2=0). Reachable? PE=-9.81*3=-29.43 ≤ 0.149 ✓, KE=29.58. Yes reachable. So bob2 reaches 2L below pivot. Down reach=2L=2. Good.

So the original layout works. But to be extra safe (since the system is chaotic and I want to guarantee "visible"), let me add a bit more margin at top and use the correct upReach bound (~0.55 to be safe) rather than assuming 0. The original used extent=2.4 (just for downward 2.0 + 0.4 margin) and didn't account for upward. Let me make it robust: account for both up (~0.55) and down (2.0).

Let me update layout to:
```
const upReach = 0.55 * (L1+L2)/2... 
```
Hmm, simpler: upReach_units = 0.55, dnReach_units = (L1+L2) = 2.0. 
scaleW = availW / (2*(L1+L2))  // horizontal ±(L1+L2)
scaleH = availH / (upReach + dnReach)  // vertical
scale = min(scaleW, scaleH, 300)
pivotY = topMargin + upReach*scale
```
With upReach=0.55, dnReach=2.0, height=2.55. For 640, margin=40: availH=560, scaleH=560/2.55=219.6; availW=900,scaleW=450; scale=219.6→cap 300 no. pivotY=40+0.55*219.6=40+120.8=160.8. Down: 160.8+2*219.6=160.8+439.2=600 < 640-40=600 ✓. 

Good, this is robust and looks like a pendulum hanging from upper area (pivot at ~25% height). Let me use upReach=0.6 to be safe (gives margin), dnReach=2.0.

Actually, let me reconsider: is there any chance bob2 goes above 0.6? The bound is 0.5076, so 0.6 is safe margin. Good.

Hmm, but actually I realize there might be even larger upward excursions if the lower bob whips around. No — the energy bound is rigorous: PE ≤ E at all reachable configs (since KE ≥ 0). The min y2 is exactly 0.5076 as derived. So 0.6 is safe. 

Let me update the layout function accordingly. The original used `extent = 2*L1 + 0.4` = 2.4 and pivotY = csh*0.22. The downward reach 2.0 + the +0.4 was margin. But it didn't reserve upward space. With scale based on 2.4, and upReach 0.55*... let me just rewrite cleanly.

Let me also double check horizontal: bob2 x2 = sinθ1+sinθ2, max |x2| = 2 (θ1=θ2=90° or both ±90). At θ1=90,θ2=90: 2(0)+0=0≥-0.0152 ✓, PE=0, reachable. x2=2. So horizontal reach ±2. ✓. width 4 units.

Let me rewrite layout. I'll set:
```
const UP = 0.6*(L1+L2)/2; // =0.6? no. Let me use absolute: upReach=0.6, dnReach=2.0, lrReach=2.0
```
Wait L1+L2=2. upReach=0.6 means 0.6 units. dnReach=2.0. lrReach=2.0.

Let me just write:
```
const upR = 0.6, dnR = (L1+L2), lrR = (L1+L2);
const margin = Math.min(csw, csh)*0.05;
const sW = (csw - 2*margin)/(2*lrR);
const sH = (csh - 2*margin)/(upR + dnR);
scale = Math.min(sW, sH, 300);
pivotX = csw/2;
pivotY = margin + upR*scale;
```

For 980×640, margin=32: sW=(980-64)/4=229, sH=(640-64)/2.6=221.5, scale=221.5. pivotY=32+0.6*221.5=32+133=165. down=165+2*221.5=165+443=608, top=165-0.6*221.5=165-133=32 ✓.

Good. Let me update the code's layout function.

Also bob radii: R1=min(18,0.095*scale)=min(18,21)=18; R2=min(14,0.075*scale)=14. OK.

Now let me make the edit to the layout function. Current code:
```
function layout() {
    csw = canvas.clientWidth;
    csh = canvas.clientHeight;
    const dpr = Math.min(window.devicePixelRatio || 1, 2);
    canvas.width = Math.round(csw * dpr);
    canvas.height = Math.round(csh * dpr);
    const extent = 2 * L1 + 0.4;            // full reach + margin
    scale = Math.min(csw * 0.95, csh * 0.90) / extent;
    scale = Math.min(scale, 300);
    pivotX = csw / 2;
    pivotY = csh * 0.22;
    needLayout = false;
}
```

Replace with robust version.

Let me edit.

Let me find the exact layout function text to replace it.

Now let me reload and test again to make sure nothing broke. Let me also verify the starting pose by checking that bob1 is at 120° (up-right) and bob2 near -10°.

Let me reload and check console + run a bit, then test pause/reset again.

Actually, I want to verify the motion is actually coupled and the rods stay rigid. The energy conservation (RK4) already confirms the physics integration is working. Let me reload and re-check the controls work, and verify motion by letting it run and checking energy updates.

Let me reload.

Good, initial load shows energy 0.149, no errors. Let me let it run for a bit to see the energy drift and confirm motion. Let me click Pause at (957,110) — but wait, with the new layout, the pivot moved to y~165, and the UI buttons are still at top right of .app. The .app position is the same (centered). The buttons y: app top=80, UI top:14 → button top=94, center y~110. So Pause click at (957,110) should still work. But let me re-verify the horizontal: app width still 980, left 110, so Pause center x~957. Same. Good.

Let me run it a few seconds, then click pause to confirm motion runs, check drift, then resume+reset.

Let me sleep and screenshot (won't show image but let me check console/dom after running). Actually let me click pause to freeze, check energy drift accumulated, then resume, then reset.

Let me first let it run 3 seconds then click pause.

Now let me click Pause to freeze the motion, then check that the drift stops updating (energy stays fixed).

The button toggled to "Resume" (paused=true). Now the drift stopped at -0.09%... wait, it shows -0.09% but earlier after 3+ seconds it was -0.45%. Now it shows -0.09%? That's odd. 

Oh wait — I reset at the end of the previous test? No. Let me re-trace. After the layout edit, I reloaded (fresh, reset state, energy 0.149). Then I slept 3s and clicked pause. The dom shows "energy: 0.149 (-0.09% drift)". 

Hmm, -0.09% drift after 3 seconds seems low compared to earlier -0.45% at some point. But drift depends on trajectory. Actually earlier the -0.45% was after I had done reset test which ran more total time. The drift rate varies. -0.09% after 3s is plausible with RK4 at dt=1/120. Either way, it's excellent.

Actually wait, the updateEnergy only logs every 400ms. After pausing, the drift display freezes. The value -0.09% is the last value before pause. The fact that pause stopped the drift from growing confirms pause works (no further energy change because physics stops). Good.

Actually, I can't see "further" without another check. But the button text changed to "Resume" which only happens if paused=true, and the handler sets paused=true. So physics loop won't step. That's confirmed by code.

Now let me confirm the motion ran for 3 seconds (drift went from 0 to -0.09%, showing rk4Step executed and energy function ran). Actually the initial was 0.149 (no drift shown at t=0 since e0 just set, drift computed as 0). After 3s it's -0.09%. So yes motion ran. Good.

Now let me click Resume to unpause, then test Reset. Resume at (957,110), then Reset at (1040,110).

Let me click Resume, then Reset.

Resume toggled back to "Pause" (paused=false). Now let me click Reset at (1040, 110).

Reset restored: button shows "Pause", energy back to 0.149 (no drift, fresh start), trail cleared (trail.length=0 in code). 

Now, the one thing I couldn't directly verify is the visual rendering (canvas pixels) since the browser tool doesn't support image capture. But:
- No JS errors in console ✓
- Energy conservation excellent ✓
- Pause/resume/reset all work ✓
- Layout keeps pendulum visible ✓

I'm confident the simulation is correct. Let me do one final check — let me verify the canvas is actually being drawn to by checking that render runs (it does, since the loop runs and energy updates require the loop). The canvas element exists in the DOM.

Let me also double-check the starting pose is correct: θ1=120° means bob1 is up and to the right (sin120°=0.866 → right, cos120°=-0.5 → up). So bob1 is upper-right, bob2 hangs with θ2=-10°. This is the correct initial pose per requirements (120° and -10° from downward vertical, zero angular velocities).

I think everything is verified as much as possible. The only unverified thing is the actual visual pixel output (colors, trail rendering, rods visible) since the tool can't capture screenshots. But the rendering code is straightforward canvas drawing with no errors, and layout math confirms positions are on-screen.

Let me make sure the file is saved (it is — write + edits applied). Let me do a final read of key parts to confirm correctness, then report.

Actually, let me reconsider one thing: the requirement says "a colorful fading trail at the lower bob." My trail renders rainbow-ish hues (hue sweeps 190→360) with alpha fade based on age, plus glow. That's colorful and fading. ✓

"Draw a fixed pivot, both rods and bobs" ✓.
"Keep both rod lengths constant" — the simulation uses rigid rod constraints by the equations of motion (constant L1, L2). ✓
"the pendulum visible" — layout ensures full reach fits. ✓
"Provide Pause/Resume and Reset" ✓
"numerically stable integration scheme and time step so ordinary playback does not explode or freeze" — RK4 at dt=1/120 with energy drift <0.5%. ✓
"without damping or external driving" ✓ (no damping terms)
"coupled equations of motion rather than independent sine-wave animations" ✓
"equal masses and rod lengths, gravity 9.81, initial angles 120 and -10, zero initial angular velocities" ✓

I'm confident. Let me verify the file one more time for the final saved state, then report. Let me read the layout section to confirm the edit applied cleanly.