A Byte of PhysicsLogo

Chaos in gravity

Some gravitational systems are deterministic yet highly sensitive to initial conditions. In a three-body setting, a tiny difference can grow into visibly different future paths.

Think like a programmer

Run paired simulations with a fixed seed and a deliberately tiny initial offset. Plot their separation on a logarithmic scale, while also verifying that both runs satisfy the same numerical-quality checks.

Model checklist

Inputs
Shared model, paired initial states, small offset, time step, and integrator.
State
Two state arrays and their separation.
Rule
Advance both identically and measure divergence.
Output
Sensitivity profile rather than one “chaotic” screenshot.
Check
Changing only the offset changes divergence, not implementation ordering.

Loading the interactive visual. The lesson text and model remain available while it starts.

A paired run needs one difference only

Serialize one initial state array of masses, positions, velocities, source ordering, softening length, integrator, time step, and output times. Make a second packet by changing one explicitly named component by a small (\delta). Both solvers then read their own immutable previous arrays, accumulate unordered pair interactions in the same order, and advance for the same physical times.

Measure a labelled norm, for example:

\[d(t)=\sqrt{\sum_i\lVert\mathbf r_i(t)-\widetilde{\mathbf r}_i(t)\rVert^2}.\]

Also log total momentum, energy, angular momentum, close-approach distances, and any regularization. Divergence while these diagnostics are uncontrolled is a numerical experiment that has not yet isolated its cause.

Read the growth window carefully

Plot (d(t)) on a logarithmic axis only where it is above roundoff and below the characteristic size of the system. A later plateau can mean the two states have simply become unrelated within a bounded region; it does not give a growth rate. If you estimate a finite-time exponent, state the fitted time window, norm, perturbation magnitude, and units.

Run controls before a chaos claim: the zero-offset pair must replay identically, a two-body reference should stay predictably regular, reversing a deterministic serialization should not alter the answer except for documented floating-point reductions, and smaller time steps or a second integrator should preserve the qualitative separation window. A blue Three.js orbit view is helpful for spatial intuition, but saved numerical traces and invariant residuals are the evidence.

Close encounters are especially dangerous. A softening length changes the physical potential; event-driven collisions, adaptive time steps, or random forcing change the reproducibility contract. Record each choice and avoid treating finite-time sensitivity as a universal prediction of a real astronomical system.

Try this experiment

Prediction: Two nearby multi-body states can separate while each still obeys the same equations.

Name one source of accidental divergence that must be ruled out before calling a result chaotic.

Where this model breaks

Finite precision and numerical error also grow. Chaos claims need convergence checks across time steps and integrators, not merely two different pictures.

Summary

Chaos is sensitivity in a deterministic model. Compare packets with one declared perturbation, control invariants and convergence, and report an unsaturated, norm-defined separation window rather than one dramatic orbit picture.

Glossary

Self-check

  1. What paired states should a chaos experiment use?
  2. Why fix the seed and update ordering?
  3. What numerical checks are necessary?

Sources

Model contract

Treat the lesson as a small function before treating it as a fact to memorize. Give every value a unit, keep only the state needed for the next step, and make the output easy to inspect.

\[\text{observable output} = f(\text{inputs},\,\text{state})\]
Inputs
Quantities you set or measure, with units and useful bounds.
State
Values the program must retain to reproduce the next result.
Rule
The relationship or update that turns inputs and state into a result.
Check
A known limit, unit check, invariant, or measured result that can expose a bad model.

Implement the idea as a model

For Chaos in Gravity, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Gravitation, the useful program is not the drawing: it is the smallest explicit model that makes a prediction you can test.

Guided experiment

Prediction: changing one declared input while holding the others fixed should change only the outputs that the model connects to that input. Choose one input, predict the direction of change, then check a limiting case such as zero, a symmetric arrangement, or a familiar low-speed or small-change approximation.

Where this model breaks

This lesson is a teaching model, not a complete simulator. Before using it outside the stated question, check which interactions, scales, uncertainties, boundary conditions, and measurement limits it leaves out.

Summary

Treat Chaos in Gravity as a contract: named inputs and units enter a rule, the rule produces an observable result, and a known limit or invariant checks whether the implementation deserves trust.

Glossary

  • Input: a measured value or chosen parameter supplied to a model.
  • State: the smallest set of values needed to continue or reproduce a model.
  • Validation: comparing an output with a known result, limit, invariant, or measurement.

Self-check

  1. Which values are inputs, and which values must remain state?
  2. What observable result would tell you the model is behaving as expected?
  3. Which assumption would you test first before applying the model to a real system?

Model review: turn Chaos in Gravity into a test

Design reproducible paired gravity simulations that test sensitivity without confusing it with numerical error.

  1. Name the inputs and units that the gravitation model needs.
  2. Separate the state you must keep from values you can calculate when needed.
  3. Write one rule that maps the current state and inputs to an observable result.
  4. Choose a limiting case, unit check, invariant, or known result before trusting an output.
  5. State one assumption you would change before using this simplified model for a real decision.

Share to: