Gravity simulator [flash] - try "Generate proto disk"
nowykurier.com
nowykurier.com
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.Deleted my other comment as you replied sorry, it is 12 am and I am not explaining myself to my satisfaction.
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
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.
http://en.wikipedia.org/wiki/Supermassive_black_hole#Superma...
I played the demo on my PC a year ago.
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 picked up Osmos during Steam's xmas sale, the game is a lot of fun and really original.
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.
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.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.
[1] http://gafferongames.com/game-physics/integration-basics/
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.
This simulation is built around Euler integration - which is pretty much the easiest numerical integration technique:
http://en.wikipedia.org/wiki/Euler_method
Even with fairly simple differential equations and numerical integration techniques you can model some really interesting stuff.
That's not entirely true as there are higher order effects in GR canceling this lag "to second order".
http://math.ucr.edu/home/baez/physics/Relativity/GR/grav_spe...