The clustertcrt_\mathrm{cr} = Myrdrag to orbit
t = 0.0 Myr
paused — press run
heaviest 10%lightest half
rh(t)/rh(0)r_h(t)\,/\,r_h(0)t  [Myr]t\;[\mathrm{Myr}]
integrator
Energy driftFSI4 · boundedΔE/E|\Delta E/E|
ΔE/E|\Delta E/E|t  [Myr]t\;[\mathrm{Myr}]

Press run with no gravity selected. Every star keeps the velocity it was born with and flies off in a straight line, and within a few million years there is no cluster left — nothing was ever holding it together. Now pressgravity: the run restarts from the same initial conditions and keeps going. The same stars, the same velocities, one term added — and now they hold.

That one term is the entire model. Every star is pulled by every other star, so the acceleration of star ii is just the sum of those pulls:

r¨i=Gjimjrirj(rirj2+ε2)3/2\ddot{\mathbf{r}}_i = -G \sum_{j \neq i} m_j \, \frac{\mathbf{r}_i - \mathbf{r}_j}{\left(\left|\mathbf{r}_i - \mathbf{r}_j\right|^2 + \varepsilon^2\right)^{3/2}}

That is the only equation being solved. Nothing in it says heavy stars should sink. Nothing in it builds a binary, or decides when a cluster comes apart, or knows what a cluster is. Everything below is this one sum, evaluated for every pair of stars, over and over — so when the heaviest stars end up in the middle, this is what put them there, and that is what makes it a result rather than a setting. The single liberty taken is ε\varepsilon, the softening: it keeps the pull finite when two stars pass very close, and the note under the figure says how large it is.

With gravity on, the two curves in the right-hand panel start together at 1 and then part — the heaviest stars contracting below where they began while the lightest climb away. That is a measurement rather than an impression: the same stars are followed all run, so the curves cannot separate by relabelling who counts as heavy. Each is drawn relative to its own starting radius, because the heaviest 10% is a small enough group that its absolute radius is a noisy number; the two absolute radii are in the readout, and at the start they differ by sampling alone.

A gap between those curves is not by itself the evidence, and it is worth seeing why. Run it with gravity off and the two separate anyway, because the heavy and light groups simply start at different radii and with different speeds. How far they separate is an accident of the draw rather than a result: measured across eight consecutive draws, the gap after eight crossing times ran from22%-22\% to +40%+40\%, and in three of the eight it was the heavy group that spread faster. What gravity does is different in kind rather than in size: the heavy curve drops below 1 while the light one climbs away. That crossing is the segregation; the offset is not.

Watch the energy strip along the bottom while gravity is on. It plots the fractional energy error against the tolerance the run is checked at, and for the first several crossing times it sits around 10910^{-9} — the integrator is barely working. Then it climbs, in steps. Each step is not a generic "close encounter": it is one specific thing, and the panel above will tell you when it happens.

The cluster builds a binary, and then the binary breaks the arithmetic.Segregation sinks the heaviest stars to the centre, where two of them capture each other — and a hard binary hardens, giving up energy to every star that passes it. Watch the readout while it happens: the pair's orbit tightens until a single orbit takes a few dozen integrator steps instead of thousands, while its binding energy climbs from a few times a typical star's kinetic energy to hundreds of times it. Once an orbit takes only tens of steps, a fixed step cannot follow it through closest approach, and the error jumps. It then sits flat until the next jump — which is exactly what a symplectic scheme should do: the error arrives in discrete events and does not creep between them.

So the strip is measuring two things at once, and it is worth keeping them apart. Thesteps are real cluster physics — binaries form and harden, and that is a result, not a bug. The height of them is a statement about this browser's arithmetic. Let it run and some clusters climb to the limit; others never do. When one does, the run ends. It would be easy to keep integrating and let the picture go on looking convincing, and that is exactly the problem: past that line the arithmetic is no longer solving these equations well enough for the picture to mean anything, so the panel stops and says why rather than showing you a cluster it is no longer computing. With gravity off the strip stays empty, because there is no integrator running to make a claim about.

So what would a real code do instead of stopping? Shorten the step. That is not something this scheme can do as a habit — its well-behaved error comesfrom the step being fixed, so a step that changed at every one of them would trade a visible, bounded error for an invisible, creeping one. But changing it a handful of times is a different object: the error takes a single jump at the change and then sits flat again. Add ?autostepto the address and the run shortens its step as the error climbs instead of ending, at roughly half the model time per second of wall clock. It costs the halt, which is why it is not the default — the line above is the honest thing to show first. The note under the cluster says when the step moved.

Run the same cluster twice and you may not get the same ending. That is not a flaw in the model; it is the thing the model is about. The error is not spread evenly over the run — it is delivered in single close passages between stars, and a close passage magnifies whatever difference it is handed. So a discrepancy far below anything visible on screen is enough, a few encounters later, to decide whether one passage lands just inside the limit or just outside it. The same draw can stop in one browser and run on in another for exactly that reason. A cluster core is chaotic in the strict sense: the individual trajectory is not something you can pin down and keep — only the statistics are, which is why a real study runs a cluster many times and quotes a distribution instead of a number.

Drop N and the curves get noisier: with few stars, segregation is a statement about an average that barely has enough members to be an average. This is the same sampling problem the census shows at the high-mass end, arriving from the other direction.

What this model does and does not know. The integrator is a symplectic scheme of the same family my gravax code uses, run here on a few hundred stars so it keeps up with a browser; gravity is softened at small separations (ε=0.1rhN1/3\varepsilon = 0.1\,r_h N^{-1/3}, about 0.009 pc atN=400N = 400), so very close encounters are smoothed rather than resolved.

The stars move but they do not age: masses, temperatures and luminosities are ZAMS values held fixed for the whole run. That is a limit on the dynamics and not only on the picture. The most massive star is a different star in every draw — measured across eight consecutive draws it ran from 16 to 47 MM_\odot — and even the lightest of those would leave the main sequence within about 12 Myr, the heaviest within about 4, returning most of its mass. This run keeps integrating them at their birth masses throughout. Past a few tens of Myr the cluster you are watching is a cluster of stars that would no longer exist, and the energy strip cannot tell you that: a conserved energy says the integrator solved the equations it was given, not that those equations still describe a star cluster.

The segregation you are watching is earned: the initial conditions place stars without regard to mass, so nothing here arranges the heavy ones and the arrangement has to come from the gravity you switched on.