Every story about an asteroid flyby comes down to one number: how close it came. This post is about how that number gets computed, and why the obvious way of computing it is wrong in a very particular direction.
The obvious way is the one anybody writes first. Step the asteroid and Earth forward together, say once a day, work out the distance at each step, and report the smallest. It is simple, it cannot crash, and it always returns a sensible-looking number of kilometres. It is also wrong by up to hundreds of thousands of kilometres, and always too far away. A flyby it measures looks safer than the real one.
A pass whose answer is known
To show that, I need a flyby where the right answer is known in advance. So I did not use a real asteroid. The engine behind these posts builds one: it takes Earth's centre at 06:00 UTC on 11 May 2028, puts a body 40,000 km away from it, and gives that body Earth's velocity plus a push of 15.6 km/s at right angles to the offset. By construction, that body passes 40,000 km from Earth's centre at that instant. Then the engine flies it forward and back on its own orbit round the Sun, and nothing in the search knows where the answer is.
40,000 km is about a tenth of the way to the Moon, and slightly inside the ring where geostationary satellites orbit, which is 42,164 km from Earth's centre. An asteroid coming that close would be news.
The obvious method, and the hour you started
Here is the obvious method run on that pass, sampled once a day over an 80 day window. The only thing that changes from one run to the next is the hour the window starts. The step and the window length stay the same.
Depending on when the search happened to start, the same pass is reported anywhere from 40,000 to 674,582 km away. At its worst that is seventeen times too far and well beyond the Moon. Averaged over every start hour it is 338,000 km, more than eight times too far.
The reason is plain once you see it. Near the closest point the asteroid moves in almost a straight line past Earth, so its distance at a time t from the pass is
d(t)² = d_min² + v² (t − t_min)²
At 15.6 km/s, being twelve hours away from the true pass adds 674,000 km. The daily samples land wherever they land. If one happens to fall right on the pass, you get the right answer. If the nearest sample is twelve hours off, you get the distance the asteroid had half a day earlier or later. The smallest sample can only be larger than the true minimum, never smaller, because the true minimum is the smallest the distance ever gets. So every error in this method makes the flyby look safer than it was.
A finer step only shrinks the error
The natural fix is to look more often. It helps, and here is exactly how much:
Sampling hourly, the worst case is still 48,860 km, 22 percent too far. At one minute it is within 3 km, but that costs 115,200 distance calculations for an 80 day window, and it is still an overestimate: smaller, but pointing the same way. The error shrinks with the step and never changes sign.
The fix is not a finer step. It is to stop treating the smallest sample as the answer. The smallest sample tells you where the pass is: somewhere between the samples either side of it. That bracket is a measurement problem with a well known solution. The engine narrows it by golden-section search, which shrinks the interval by the same ratio each time, until it is one second wide. From a two day bracket that takes 29 more distance calculations. At every step size and every start hour it returns 40,000 km, and it agrees with the construction to under a metre. The refined answers from four different start hours differ from each other by 2.4 centimetres.
Try it. The pass below is the engine's, exported every ten minutes. Change how often you look and when you start, then press refine.
The pass, sampled once a day
Here is what daily sampling sees, drawn to scale in Earth's frame:
At 15.6 km/s an asteroid covers 1.35 million kilometres a day, three and a half times the distance to the Moon. The daily samples are so far apart that the whole encounter happens between two of them.
Three more places the same number goes wrong
Sampling is the big error, but it is not the only place a close-approach number can quietly come out wrong. The engine checks for each of these:
Measuring to the wrong Earth. Ephemerides give the Earth-Moon barycentre, the point the two orbit around together. It sits inside the Earth, about 4,670 km from the centre, and moves around with the Moon every month. Measured to that point, this pass comes out at 38,096 km instead of 40,000: 1,904 km wrong, almost five percent, from using a point that is a perfectly correct answer to a different question. The engine measures distance to Earth's actual centre, which it gets from its own lunar model, and reports the barycentre figure next to it so the difference is visible.
Leaving out Earth's gravity. This one is a limit of the engine, so I am stating it plainly. Its asteroid orbits are two-body orbits around the Sun. Earth's own pull on the asteroid as it passes is not in the model. For this pass that pull would bend a 40,000 km straight line in to about 38,393 km, by the standard hyperbolic-orbit formula. So the refined number is exact for the model, and the model is a little generous.
A close approach is not the hazard number. The distance that decides whether an asteroid goes on the potentially hazardous list is the MOID, the closest the two orbits come to each other, with timing taken out. For this constructed asteroid the MOID is 877 km. That is less than Earth's own radius: the two paths come closer together than the width of the planet, while the two bodies, on this pass, miss by 40,000 km. They miss because Earth is not at that point in its orbit when the asteroid is. The reverse happens too. Earth and Mars have orbits that come within 0.373 AU of each other, and over the whole decade after this pass the planets themselves never get closer than 0.380 AU. Orbits crossing and bodies meeting are different questions, and the engine returns both.
It also refuses to answer when the step is too coarse to see the orbit at all. Asked to sample every 60 days, it replies a 60 day step cannot resolve a 365 day orbit; use 18.26 days or less, rather than handing back a confident subset of the real approaches.
The pattern
This blog keeps finding one shape of mistake: a method that returns a well formed answer that happens to be false. The sampled close approach is a clean example. The output is always a sensible number of kilometres, never an error, and it depends on something that has nothing to do with the asteroid: the hour the search started. The error also always points the same way. Every mistake makes the pass look farther and safer. That is the most dangerous direction for an error to point, because nobody goes back to check a number that says everything is fine.
The fix is cheap: 29 more calculations and a rule that the coarse scan brackets the answer and never measures it. The engine follows that rule everywhere it reports a close approach.
What is not modelled
- Earth's pull on the pass, as above: two-body orbits around the Sun only, so a real pass this close would come about 1,600 km nearer.
- A real asteroid: this encounter is constructed so its answer is known. The engine can load catalogue elements, but the catalogue could not be reached from where this was written, and I would rather show a constructed pass labelled as one than a real one from memory.
- Uncertainty in the orbit: a real close approach comes with an error ellipse from the orbit determination, which is often far larger than any of the errors here.