Task 1 of 6

One Thread, One Whole Trajectory

A mass on a spring, in one line: the acceleration always points back at the origin, a = −x. That is the entire physics of this module. It is deliberately the dullest force there is, because the subject here is the clock, not the force — N-Body Gravity owns interesting forces.

What the spring buys is that we already know the answer, exactly and forever:

x(t) = x₀·cos t + v₀·sin t
E    = (x² + v²) / 2, constant

So every number a solver produces can be subtracted from the truth, and "how wrong is this?" stops being a feeling. And the GPU shape flips. N-Body's tick loop runs in JavaScript, one launch per step, because every body needs every other body's new position before the next tick — that is a barrier. These trajectories never speak to each other, so the loop moves inside the kernel: one launch, one thread, one entire trajectory, a thousand at a time.

the clock moved inside the kernel — one launch, one thread, one whole trajectory

Goal: fill in one explicit-Euler step, so each thread integrates its own oscillator for 200 steps and returns the final x.

Requirements

The time loop stays inside the kernel — this.constants.steps iterations, one thread per trajectory
Explicit Euler commits to the start of the step: take a = −x first
Advance x by the step-start v · dt, and v by a · dt
Return this thread's final x

Hint 1 — what one step is

Three lines. The acceleration first, because x is about to change under it:

const a = -x;
x = x + v * dt;
v = v + a * dt;

Hint 2 — why that order

Explicit Euler uses only step-start values. Writing v first and then moving x with the new v is a different method — semi-implicit Euler, the one N-Body Gravity steps with. It is better, and it is task 5's business. Here we want the naive one, because its badness is the lesson.

Hint 3 — no arrays inside the loop

x and v are plain let locals. The arrays are read once, before the loop, to start this thread off — after that the whole trajectory lives in two registers.

Same idea elsewhere

One thread per independent problem is how GPUs are pointed at ODEs everywhere: CUDA and HIP ensemble solvers give each thread one particle's trajectory, WebGPU compute does the same for particle systems, and the "batched" families in cuBLAS and cuSOLVER exist because thousands of small independent problems are the shape this hardware likes best. The kernel is the solver; the launch is the ensemble.

All tasks in ODE Integrators

This page is an interactive exercise — the editor, the GPU runner and your saved progress need JavaScript. The text above is the full brief.