Science Journaling Club Founded 2024

INTERACTIVE COMPANION · FIELD NOTES · SEISMOLOGY

The Slip Bench

A live model accompanying “Caught on CCTV: The First Video of a Fault Tearing the Ground Apart”

← Read the full article

A security camera in central Myanmar recorded 1.3 seconds on 28 March 2025 that nobody had ever filmed before. The ground on one side of the Sagaing Fault slid 2.5 metres past the ground on the other. Below you can build that pulse yourself, and then face the problem the authors faced, which is getting a number out of 31 blurry frames.

Both models compute everything live. Nothing here is a stored answer. Nothing here is the authors' analysis either; it is the club's own simplified forward model, the same one that produced the figures in the article.

Model 1 · Shape the pulse, watch the fence tear

A slip pulse is described by three numbers you can actually measure: how far the fault moved (\(D\)), how long it took (\(T\)), and how fast it got at its fastest (\(v_{\max}\)). Those three fix a dimensionless shape number, the fraction of its bounding rectangle that the velocity pulse fills:

$$k \;=\; \frac{D}{v_{\max}\,T}$$

A flat-topped boxcar fills the whole rectangle, so \(k = 1\). A triangle fills exactly half of it. A sharp crack-tip spike fills a good deal less than half. The published numbers give \(k = 0.601\), which is flatter-topped than a triangle, and that single fact is the most interesting thing about them.

What to try. Start with peak slip velocity. Drag it up and the shape factor in the readout goes down, because a faster peak covering the same 2.5 m has to be a peakier pulse. Now drag rise time to peak: the velocity curve leans forward or back, and \(k\) does not move at all. Pulse duration stretches the whole event in time. Watch the verdict line under the plots while you do any of this. It tells you, at every setting, whether a textbook crack-tip pulse could have produced that combination of numbers, and whether the bow in the slip path would have been big enough for the camera to see.

total slip: shape factor k: peak velocity: rise 5→95%: sagitta: arc − chord:

Why the rotation slider is the whole paper

The fence offset in the top panel is the part everyone notices. The panel on the lower right is the part that got the paper published: the route the fault took to get there, drawn in the plane of the fault itself.

Set slip-vector rotation to 0° and that route is a straight line. One block slides cleanly past the other along strike, which is the textbook picture. Set it to the observed 35° and the path bows out. The first metre of slip is oblique, then the vector swings round and runs straight. Field geologists have been photographing that shape for decades, frozen into the scratch marks on exposed fault surfaces, arguing about what it meant. Those scratches are called slickenlines. A scratch has no timestamp. A video does.

What to watch. Turn the rotation slider slowly and keep your eye on the sagitta and arc − chord readouts. At 35° the path bows 19.3 cm off its own chord, while the whole curved route comes out only 38 mm longer than the straight one. That 38 mm is buried a full order of magnitude inside the ±0.5 m uncertainty on the offset itself. A tape measure laid across a fresh rupture reads the chord and nothing else. Curvature is a shape. A tape measure returns a length. That is precisely why forty years of field measurements could never settle the question.

At this camera's scale, 13.2 pixels per metre, that 19.3 cm bow is 2.55 pixels. Two and a half pixels is the entire discovery.

Now drag the rotation down to 5°. The sagitta readout falls to about 0.37 px, which sits right on the 0.3 px floor of sub-pixel cross correlation. The verdict line still calls that a detection, barely; no referee would. At 3° it reads 0.22 px and the bow simply does not exist as far as this camera is concerned. There is no paper at 5°. The Sagaing Fault happened to turn far enough, in front of a camera close enough, for the signal to clear the noise.

Model 2 · Measure it yourself

Here is the same pulse as the camera sees it: 30 frames per second, one tracked patch, and a position that jitters because sub-pixel cross correlation is good but not perfect.

What to do. Click the centre of the marker in each frame, then press next frame. Your clicks build the measured displacement curve on the right, and the velocity curve below it is computed from those same clicks by differencing consecutive frames. Watch the two curves against each other. The displacement curve will look fine while the velocity curve falls apart, and that gap is the whole lesson. Tracking noise σ sets how far the marker strays from where it really is, in camera pixels. Velocity smoothing runs a moving average over the differenced velocity before anything is read off it. The frame-rate selector rebuilds the filmstrip from scratch.

frames measured: 0 your RMS position error: resulting RMS velocity error: predicted σv: peak velocity you recover:
Filmstrip · 30 fps · click a frame to jumpclub forward model
Each cell is one video frame. The real CCTV ran at 24 fps, so the whole 1.3 s pulse is 1.3 × 24 ≈ 31 frame intervals, and just 12 of them fall in the half-second where all of the curvature lives.

Why differentiating video amplifies noise

Displacement you measure. Velocity you compute, by subtracting one frame's position from the next and dividing by the time between them. That division is the problem. If each position carries a random error of \(\sigma\) metres, and consecutive frames are \(\Delta t\) apart, the error on a central-difference velocity is

$$\sigma_v \;=\; \frac{\sigma}{\Delta t \sqrt{2}}$$

Put the real numbers in. At this camera's scale 0.25 pixels is 1.89 cm, and at 30 fps \(\Delta t\) is a thirtieth of a second, so \(\sigma_v = 0.0189 / (0.0333 \times 1.414) = 0.40\) m/s. That is 13% of the 3.2 m/s peak we are trying to measure, produced entirely by a position error smaller than a fingernail. Set the noise slider to 0.25 px, leave smoothing at zero, press auto-measure all, and read the predicted σv against the measured one. They agree, to within the scatter you would expect from a single run of forty frames. The formula is not a fudge.

Worse, the peak is biased. Our Monte Carlo run over 4,000 trials recovers a peak of 3.77 ± 0.21 m/s where the truth is 3.20, an 18% overshoot. Taking the maximum of a noisy series is a rigged game. You are selecting whichever frame the noise happened to push furthest up. Nobody is cheating. The arithmetic does it for you.

So you smooth, which is what the authors did: a 0.2-second moving average before quoting a peak. Push the smoothing slider to 0.20 s and watch the velocity curve calm down. Random error falls roughly as the square root of the number of frames you averaged. At 30 fps that is six frames, and our Monte Carlo cut the RMS error from 0.40 to 0.13 m/s. The readout under the canvas runs one seeded draw rather than four thousand, so expect it to land near that figure rather than exactly on it.

Smoothing is not free, and this is the honest part. Averaging a curve with a peak in it flattens the peak. Even with a perfect noiseless camera, a six-frame moving average shaves 1.3% off the true maximum. You have traded a random error you can quantify for a systematic one you cannot escape. Two error terms move in opposite directions as you turn one knob. There is an optimum somewhere in the middle, and there is no setting anywhere with no error at all.

What this bench cannot tell you

Several things, and they matter.

The pulse shape is assumed. We picked a two-parameter smoothed ramp because it can hit all three published numbers at once, which the classical crack-tip function provably cannot. Fitting a curve to three numbers is no kind of discovery, and a different family of curves would give you different accelerations off the same three numbers.

The rake law is fitted to four published targets whose error bars are enormous. The transient dip slip is 0.3 ± 0.25 m, a signal barely clear of its own uncertainty. Our path bows 19.3 cm. The honest range on that number is wide.

The noise model in Model 2 is independent Gaussian jitter, frame to frame. Real tracking errors are correlated, because a patch that drifts one way in one frame tends to drift the same way in the next. That makes the velocity error smaller than our formula predicts and the bias harder to bound.

And the whole bench is a forward model. It shows you what follows from the published numbers if our assumptions hold. It cannot tell you whether they do. If you want the argument about what a single camera at a single site can and cannot establish, the article has a whole section steelmanning the skeptics.