Dear god, there was a solar system simulation on the macs in my middle-school library (c. 1998) that I sunk absolutely inordinate, ridiculous amounts of time into. I think it had a 10-body limit and may have been much older (was definitely monochrome, and possibly used lines of varying density for shading). I can't remember what it was called and I haven't been able to find any information about it. It may be my favourite single piece of software ever and I am certain it had some nontrivial effect on the course of my life[0].
Can anybody help me out?
[0] Including nurturing several destructive habits and attitudes, such as on the acceptability of spending grade-school lunch hour on the computer every day.
The simulation is quite bad numerically. If I start with a proto disk and then put an non-moving OMFG particle immediately to the left of it, the whole system that is initially at rest will end a with a considerable momentum to the left, even though no or almost no particles carry any momentum to the right. That is not only not to physical scale, generating momentum out of nothing is completely unphysical.
It says it uses Euler integration, what do you expect? At least the really bad interactions are mostly handled by absorbing the planets into one another, even though not all of them are.
Nice observation. The inaccuracy is greatest when masses are near, so absorbing close masses limits how near they can get. When I wrote one of these simulators, I had masses zinging off everywhere when they "collided".
Question: does this inaccuracy systemically affect the development of a "solar system" from a "proto disk"? I think, by increasing randomness, it would actually tend to work against it somewhat.
Also, the odd effect of the proto disk expanding after the sun forms is caused (I think) by masses falling into the sun, and thus further away from the rim of the disk. This greater distances reduces the gravitational force on the rim, and so their velocity ("centrifical" force) can carry them away.
It looks right in my tests, the particles accelerate towards the OMFG with a large proportion hitting the OMFG in what looks like a perfect inelastic collision, that is they merge and the velocity and mass is added to OMFG. This creates a movement to the left of the OMFG particle.
Deleted my other comment as you replied sorry, it is 12 am and I am not explaining myself to my satisfaction.
As I said in my reply to your deleted comment, this is plain wrong. Momentum is conserved. Unlike kinetic energy (which gets transformed into heat), it is even conserved in inelastic collisions.
Take two masses A and B, place them at rest near each other. They should collide and be at rest at some point between them. However, based on the inaccuracy in the way the simulation works if one of those particles is really huge they sometimes gain a lot of energy and fly past each other.
It's hard to tell if momentum is being conserved or not with so many particle, but in the example you mention there is one particle moving to the right, which is the OMFG.
So to make the test simpler, let's start with a single particle. This particle is initially at rest, just as with the protodisk, and nothing happens if we wait for a while. Adding in another particle of the same mass, we see the two particles move towards each other and meet in the middle, implying momentum is conserved. So I am thinking momentum is probably conserved for all cases, to some degree of accuracy
No, momentum is conserved, that is one of the fundamental laws of physics, right up there with the conservation of energy. In the beginning, the OMFG particle is at rest, and the protodisk particles orbit symmetrically around the center of the protodisk, for a sum total momentum of zero.
Is that a solar system I see there? It can also be a galaxy if each dot is a solar system. Makes me wonder if the galaxies are actually orbiting around something and that something is orbiting around something and so on. Turtles all the way down.
I did only buy it for my iPod Touch though. It fits the touch platform really well. I played through every single level except the last arcade level which I can't seem to beat. Damn gravity!
I wish there was a website that made the maths for all this kind of thing accessible to idiots who don't have any formal maths education (like me). I've bought a few books, but even those seem to skip a stage or two.
The math is actually really easy. Every two objects exert a force on each other of (mass 1 * mass 2) / (distance ^ 2). Pseudocode to step gravity in a simulation would be something like:
foreach(object as o1) {
foreach(object as o2) {
if(o1 != o2) {
force = (o1.mass * o2.mass) / (o1.pos - o2.pos).length
o1.vector *= unit_vector_from_o1_to_o2 * force
}
}
}
Obviously this is O(n^2), which is why it's so slow when you have a lot of objects in the system, but it's pretty straightforward.
Once you get the basic Euler setup working it is worth it to try out a more accurate integration method.
Anytime someone posts a simulation using Euler Integration someone usually links to the following[1]. It describes why Euler integration isn't good enough (with the famous line, "If you are use Euler then you are a bloody idiot"). It then proceeds to show how to implement RK4 or Runge Kutta order 4.
This method will evaluate the derivative at four points in between the previous and current timestep to detect the curvature of an objects velocity. It will then take a weighted average to get the best approximation of the derivative for that timestep. This accounts for acceleration in between timesteps rather than assuming a constant velocity between them.
Yep, and from Runge-Kutta you can get better by switching to variable (and/or independent) step size. Eg. Adaptive Runge-Kutta (variable timestep based on local error estimate from two different orders). Or you can go to predictor-corrector which is pretty interesting as well: http://www.sns.ias.edu/~starlab/kira/
Not necessarily better. It reduces the number of calculations per unit time, in some cases. Unfortunately changing the step size dynamically also increases error in the system (because of the way most integrators works). It's a trade-off between CPU time and accuracy.
I'm not sure that's the right way of looking at it. With most numerical simulations, the only thing that matters is the level of accuracy. By changing the accuracy, you change how fast it runs (less accuracy->faster). So for a given level of error tolerance, adaptive step size will typically run faster, because it can use larger steps when able, and smaller steps when required. For fixed time steps you have to stay at the smallest the whole time.
With fixed time step for the same level of error you have to stay small, but not as small as you have to sometimes go with variable timestep.
In a large-but-simple n-body simulation like this, where every body is integrated at once, variable timestep has to keep the pace of the body that potentially has the most error. With variable timestep, as you add more bodies you end up running at a fairly steady but very slow pace, not only with the slightly slower timestep but also with the added overhead of the error prediction calculations.
The solution we used when I was studying this was to group nearby bodies together, and groups could be integrated independently and at different timesteps to each other. To bodies outside the group, the group appeared as a single point mass positioned at the centre of mass of the group.
Fascinating - thanks for the link. I've unknowingly implemented the Euler method in simple games before without knowing its name, since it's the more or less intuitive way to do things - it's quite amusing to see how terrible it can be under some situations.
there are various algorithms to reduce the complexity via physically motivated approximations, see http://www.cs.cmu.edu/~scandal/alg/nbody.html for an older but accessible introduction
It's a shame that lots of maths education can actually completely miss what you can practically do with things like integration, differential equations and numerical techniques for integration.
This simulation is built around Euler integration - which is pretty much the easiest numerical integration technique:
The smaller items whipping around a larger body remind me of the footage you see on docos about the discovery of Sgr A* in our galaxy. It's mesmerising.
The force of gravity is not instantaneous. It "travels" at the speed of light. The Earth is not attracted to where the Sun is "now", it is attracted to where the Sun was approx. 8 minutes ago (the length of time it takes for light to travel from the Sun to the Earth), and vice versa.
Can anybody help me out?