Moscow, 1936: V. S. Lukyanov builds a computer out of water. Level in a row of glass vessels stands for temperature; water flows between them through calibrated tubes at a rate set by the level difference — and that is exactly the heat equation uᵗ = D·uₓₓ. This panel is runnable: it steps the machine’s mechanism (the explicit FTCS scheme), converges to the analytic solution — and blows up the moment you open the tubes too wide.
source V. S. Lukyanov, the hydraulic integrator (гидравлический интегратор), 1936 — a Soviet analog computer that solved differential equations with the levels and flows of water. Room: THE MACHINE. Rendered, not quoted.
Vladimir Sergeevich Lukyanov (1902–1980), a railway engineer, built the first hydraulic integrator in 1936 to compute the thermal stresses that were cracking concrete in winter track-bed. It was a computer made of water: a lattice of vessels and tubes.
Later “IGL” machines were mass-produced and used for decades on permafrost, dam and mine heat problems — real engineering, solved by water levels, well into the 1970s.
The machine works because two different physics obey the same equation. Water level h in a vessel plays temperature u. A tube joining two vessels carries a flow proportional to the level difference — that is heat flux, proportional to the temperature difference (Fourier’s law).
Conservation of water in each vessel is conservation of heat: uᵗ = D·uₓₓ. The vessel levels, left to settle, trace the temperature field in real time. No numbers are written; the water does the integrating.
The vessel-and-tube mechanism, written in symbols, is the explicit finite-difference method (FTCS) for the heat equation. The analog machine and the digital scheme are the same algorithm — one in water, one in silicon.
When digital computers arrived, the water drained out but the scheme stayed: every explicit heat solver today is Lukyanov’s integrator, and it inherits his stability limit exactly. The analog machine was not a dead end — it was the prototype.
A rod on [0,1], ends held at 0, starts hot in the middle: u(x,0)=sin(πx). The machine steps the field with uᵢⁿ⁺¹ = uᵢⁿ + r·(uᵢ₋₁ − 2uᵢ + uᵢ₊₁), where r = D·dt/dx² is how wide you open the tubes per tick.
D=1, grid dx=1/20, dt = r·dx². The run below takes 200 ticks to physical time —.
▮ water level (FTCS) — analytic sin(πx)·e−Dπ²t
peak amplitude: start — → after run — max seen over run —
max error vs analytic at t=—: —
STABILITY. WALL The water cannot flow faster than the level difference allows. In symbols: the scheme is stable iff r ≤ 1/2. Open the tubes wider (r > 1/2) and the smallest ripples are amplified each tick — the levels oscillate and diverge. This is a physical limit of the real machine, not a bug.
this r = —
| flow r | claim | the water | agree |
|---|
The claim (“r ≤ 1/2 solves it”) is checked against the actual run: a safe r must stay bounded and decay; a too-wide r must blow up. Claim and water must agree on every row.
WHY ANALOG. Before digital machines, water integrated PDEs in real time — you built the geometry, opened the valves, and read the levels. It was slow to set up and hard to reprogram; that is the honest wall, not accuracy.
“Analog computing was a dead end.” Cut. The water integrator solved real permafrost and dam heat problems for 40 years, and FTCS — its exact digital heir — runs today.
“Take a bigger time-step to finish faster.” Cut. Past r = 1/2 the explicit scheme is unconditionally unstable; a bigger step does not finish sooner, it explodes.
“A finer grid is always safer.” Cut. Halving dx quarters dx²; to keep r ≤ 1/2 you must quarter dt too — finer space demands far finer time.
The red move: set r > 1/2 (open the tubes too wide / step too fast) but claim it still solves the equation — drop the r ≤ 1/2 check so a diverging run gets stamped solved.
Drop the limit and the claim lies about the too-wide rows: it calls them solved while the actual water (the run) blows up. The witness compares the two and turns red. The attack is real and it is caught.