Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing N-body gravity simulations code in Python

alvinng4.github.io

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Writing N-body gravity simulations code in Python

#21

Post by quantadev »

itishappy wrote: post #17
munchler wrote: post #5

In Step 2 (Gravity), why are we summing over the cube of the distance between the bodies in the denominator? Edit: To answer myself, I think this is because one of the factors is to normalize the vector between the two bodies to length 1, and the other two factors are the standard inverse square relationship.

You got it. The familiar inverse square formula uses a unit vector: a = G * m1 * m2 / |r|^2 * r_unit r_unit = r / |r| a = G * m1 * m2 / |r|^3 * r

The force itself is `G * m1 * m2 / (r^2)`. That's a pure magnitude. The direction of the force is just the unit vector going from m1 to m2. You need it to be a unit vector or else you're multiplying up to something higher than that force. However, I don't get why you'd ever cube the 'r'. Never seen that. I don't think it's right, tbh.

Re: Writing N-body gravity simulations code in Python

#22

Post by quantadev »

halfcat wrote: post #15
JKCalhoun wrote: post #14

Earlier quoted context omitted.

Decades ago ... I think it was Computer Recreations column in "Scientific American" ... the strategy, since computers were less-abled then, was to advance all the bodies by some amount of time — call it a "tick" — when bodies got close, the "tick" got smaller: therefore the calculations more nuanced, precise. Further apart and you could run the solar system on generalities.

So in this kind of simulation, as we look closer, uncertainty is reduced. But in our simulation (reality, or whatever), uncertainty increases the closer we look. Does that suggest we don’t live in a simulation? Or is “looking closer increases uncertainty” something that would emerge from a nested simulation?

The reason uncertainty goes up the closer we try to observe something in physics, is because everything is ultimately waves of specific wavelengths. So if you try to "zoom in" on one of the 'humps' of a sine wave, for example you don't see anything but a line that gets straighter and straighter, which is basically a loss of information. This is what Heisenberg Principle is about. Not the "Say my Name" one, the other one. hahaha.

And yes that's a dramatic over-simplification of uncertainty principle, but it conveys the concept perfectly.

Re: Writing N-body gravity simulations code in Python

#23

Post by kkylin »

RpFLCL wrote: post #12
the__alchemist wrote: post #11

Next logical optimization: Barnes Hut? Groups source bodies using a recursive tree of cubes. Gives huge speedups with high body counts. FMM is a step after, which also groups target bodies. Much more complicated to implement.

That's mentioned on the "Conclusions" page of TFA: > Large-scale simulation: So far, we have only focused on systems with a few objects. What about large-scale systems with thousands or millions of objects? Turns out it is not so easy because the computation of gravity scales as . Have a look at Barnes-Hut algorithm to see how to speed up the simulation. In fact, we have documentations about it on this website as wel…

C or C++? Ha! I've implemented FMM in Fortran 77. (Not my choice; it was a summer internship and the "boss" wanted it that way.) It was a little painful.

Re: Writing N-body gravity simulations code in Python

#24

Post by sampo »

JKCalhoun wrote: post #14
mkoubaa wrote: post #10

My favorite thing about this kind of code is that people are constantly inventing new techniques to do time integration. It's the sort of thing you'd think was a solved problem but then when you read about time integration strategies you realize how rich the space of solutions are. And they are more like engineering problems than pure math, with tradeoffs and better fits based on the kind of system.

Decades ago ... I think it was Computer Recreations column in "Scientific American" ... the strategy, since computers were less-abled then, was to advance all the bodies by some amount of time — call it a "tick" — when bodies got close, the "tick" got smaller: therefore the calculations more nuanced, precise. Further apart and you could run the solar system on generalities.

Adaptive time step RKF algorithm is explained in section 5:

https://alvinng4.github.io/grav_sim/5_steps_to_n_body_simula...

Re: Writing N-body gravity simulations code in Python

#26

Post by [deleted] »

antognini wrote: post #3

Once you have the matrix implementation in Step 2 (Implementation 3) it's rather straightforward to extend your N-body simulator to run on a GPU with Jax --- you can just add `import jax.numpy as jnp` and replace all the `np.`s with `jnp`s. For a few-body system (e.g., the Solar System) this probably won't provide any speedup. But once you get to ~100 bodies you should start to see substantial speedups by running the…

[deleted]

Re: Writing N-body gravity simulations code in Python

#27

Post by hermitcrab »

leumassuehtam wrote: post #18
JKCalhoun wrote: post #14

Earlier quoted context omitted.

Decades ago ... I think it was Computer Recreations column in "Scientific American" ... the strategy, since computers were less-abled then, was to advance all the bodies by some amount of time — call it a "tick" — when bodies got close, the "tick" got smaller: therefore the calculations more nuanced, precise. Further apart and you could run the solar system on generalities.

One way of doing that is by each time step delta perform two integrations, one which give you x_1, and another x_2, with different accuracies. The error is estimated by the difference |x_1 - x_2| and you make the error match your tolerance by adjusting the time step. Naturally, this difference becomes big when two objects are close together, since the acceleration will induce a large change of velocity, and a lower t…

I have run into the problem where a constant time step can suddenly result in bodies getting flung out of the simulation because they go very close.

Your solution sounds interesting, but isn't it only practical when you have a small number of bodies?

Re: Writing N-body gravity simulations code in Python

#28

Post by tanepiper »

kristel100 wrote: post #25

N-body problems are the gateway drug into numerical physics. Writing one from scratch is a rite of passage. Bonus points if you hit that sweet spot where performance doesn’t completely tank.

I built https://teskooano.space/ - so far I've not seen any big performance issues, and it's multiple bodies running happily at 120fps.

Now you're making me worry I'm not "physicsing" hard enough

Re: Writing N-body gravity simulations code in Python

#29

Post by eesmith »

Back in the early 1990s I was going through books in the college library and found one on numerical results of different 3-body starting configurations.

I vividly remember the Pythagorean three-body problem example, and how it required special treatment for the close interactions.

Which made me very pleased to see that configuration used as the example here.

Re: Writing N-body gravity simulations code in Python

#30

Post by odyssey7 »

mkoubaa wrote: post #10

My favorite thing about this kind of code is that people are constantly inventing new techniques to do time integration. It's the sort of thing you'd think was a solved problem but then when you read about time integration strategies you realize how rich the space of solutions are. And they are more like engineering problems than pure math, with tradeoffs and better fits based on the kind of system.

They're more like engineering than pure math because pure math hasn't solved the n-body problem.
Post reply on HN