A better approach to gravity: how we made EGM2008 faster

Exactly what order and degree were you using to evaluate the model? Variations in drag and solar pressure are more significant than the uncertainty in the gravity field for objects in LEO somewhere much less than 127th order (40 microseconds on my machine, your smileage may vary), so you can safely truncate the model for simulations. GRACE worked by making many passes such that they could average out those perturbations to make their measurement. But for practical applications, those tiny terms are irrelevant.

IERS Technical Note 36 section 6.1 gives recommendations for model truncation if you are looking for justification. https://iers-conventions.obspm.fr/content/tn36.pdf

Always super satisfying to take a 1.2s calculation and make it orders of magnitude faster. Recently I had a complicated calculation mostly done in SQLite (with some C callbacks to do core floating point ops) that was taking 1.5s; rewrote it into a hand-crafted incremental computation network and got the calculation down to 6ms.

Do I understand right, that it's summing ~2 million spherical harmonic terms, and the optimization is that that's accomplished in ~200 ms (per test point?)? Does this force field feed into something like a Runge-Kutta solver for predicting orbits? (I don't know much about orbital mechanics).

Related: Dr. Martin used PINN for creating a gravity model [0] and video [1].

[0] https://github.com/MartinAstro/GravNN

[1] https://www.youtube.com/watch?v=1UNtZ4sOVEI

Technical nit: spherical harmonics are used in quantum mechanics but were developed for classical mechanics.

> Who’s the fastest kid on the block now, MATLAB?

Was MATLAB ever the fastest kid?

What's outlined in the article has, from my PoV at least, been true since 1980 at least (and older coders will likely in with earlier tales): handy implementation and simulation libraries generally work and provide good reference results to check against but almost always you can get a magnitude order faster if you can put the time in.

I put the earlier pre-2008 epoch models for earths gravity and magnetics through a similar workout sometime ago, for our use case we spent some time and money to make a custom TI DSP chip pipeline to get the turn around that made data exploration playful rather than an overnight grind.

Disable NextDNS or other DNS Adblock tools if the site doesn't load the content.

What's the accuracy/speed tradeoff for thus model compared to one based on computing density points and using Barnes-Hut?

Excuse my ignorance but how big of a lookup table would you need to achieve the same outcome ?

TL;DR: JAX (the GPU-accelerated Python ML framework)

Pretty cool to see applications of all this good stuff developed for ML in other areas! I guess a side effect is that the calculations should now be differentiable and you could optimize various parameters using gradient descent if you wanted. You could even use it as a component of a neural net and backpropagate gradients through it.

Also it's not clear if they used GPUs but they probably could for an even better speedup in a scenario with large batches of calculations.

No offense but this doesn't seem "revolutionary" at all / people have been doing hierarchical representations and multipole expansions since forever. The presentation of a single fixed-resolution bitmap of dense equations with no introduction of terms feels like it's trying to do proof by intimidation.

When doing path guiding in Monte Carlo path tracing you often have lots of nasty low probability / high contribution paths that make gravitational simulation seem easy. After all, if you can a-priori simulate light paths efficiently, then you can efficiently solve optical computers / the Halting Problem.