# Thread: Help with a galaxy simulator (Gravity)

1. Member
Join Date
Nov 2007
Posts
33

## Help with a galaxy simulator (Gravity)

Hi!

I have done a small galaxysimulator, but things go horribly wrong quite fast in the simulations. I will try to describe first how it works and then the problem I get.

What it does is that it puts a number of stars in a cubic space at random positions inside that volume. Then it lets the stars interact and move according to te gravitational rules. (I will talk more about this later.)
First the stars fall in together, some stars here and there get thrown out quite fast. Stars start to rotate in random paterns around eachother and at first it looks something like a globular cluster. But when the stars have moved past the center of mass the first time and are heading out again, they have such velocity most of them just get thrown out and the galaxy gets ripped apart.

The simulator have no "speed of light" at this point, so gravity is instant.
What I want to know is if I may have done something wrong in my calculations maybe?

Each step in the simulator is one time step, so when velocity v=v0+at that means that in my simulation I calculate the new velocity each step and theirfor I get v=v0+a.

Since my simulator uses 3 coordinate system i calculate the distance in 3 coordinates at first.

distance(x, y, z) = Star1.position(x,y,z)-Star1.position(x,y,z)

To get the acctual distance i use distNorm = sqrt(x^2+y^2+z^2)

When I have done that I get the acceleration in each direction by taking acc(x,y,z) = (G*M*distance(x,y,z))/(distNorm^3)

Then I have done that I take v(x,y,z) + acc(x,y,z) to calculate the new velocity.

Anyone that can tell me if I have done some misscalculations or just thought wrong somewhere?
Or could it be that there are so fiew stars so that it isnt possible for them to hold on to eachother?

Thanks!

// Cyoor
Last edited by Cyoor; 2009-Oct-15 at 05:01 PM.

2. It sounds like your coding is correct. I'm not sure about the following line, but that's just because I don't understand it:

Originally Posted by Cyoor
When I have done that I get the acceleration in each direction by taking acc(x,y,z) = (G*M*distance(x,y,z))/(doistNorm^3)
I think your general problem is, you're not giving the point masses any initial velocity. Apparently you have all of them starting out at rest. They would all just collapse and get sling-shotted off your screen at high velocity. Galaxies have spin when they are born (apparently), so give all your point masses some initial velocity vector (perpendicular to the line between them and the system's center of mass), and you should get better results.

3. Member
Join Date
Nov 2007
Posts
33
Thank you.

They have initial velocity ( just forgot to mention it :P ) but its totally random in direction. I have now tried to give them higher initial velocity, and that works better. It looks more and more like a globular cluster now, with stars spread out in all direction and moving around in all directions.

It seems that if I give them to much initial velocity, they just go off in all directions before a "crunch" and if i give them to little velocity they crash together and then get thrown off.

If anyone got any sugestions, feel free to post them

btw acc(x,y,z) is the acceleration in (x,y,z) direction should have used acceleration(x,y,x) instead

4. ## close encounters

One reason that many stars get thrown out of the simulation at high speeds is because your equation for the acceleration of an object looks like:

acc = G*m / (r^2)

where "m" is the mass of a neighboring object and "r" is the distance between them. This is the correct equation, but it causes problems in simulations. The problems arise when "r" gets small. Obviously, if r = 0, then the acceleration becomes infinite. Less obviously, if r is small enough, the acceleration will be so large that in the next time step, the object's velocity will be given a very large value ... which will cause the object to fly out of the simulation very quickly.

In real life, yes, a nearby object will cause an object to have a very large acceleration ... but then, just a short time later, as the object moves past its neighbor, there will be a strong DE-celeration which cancels the effects of the first large acceleration. In your simulator, if the timestep is too large, the object will move so far in that first timestep with a high velocity that is leaves the neighbor far behind -- which means that the neighbor doesn't have a chance to decelerate it.

You can fix this either by adding a softening parameter (look it up) like this:

acc = G*m / (r^2 + a^2)

or by adjusting the size of the timestep so that it shrinks for objects which are passing close to each other.

There's a lot of literature on this subject, so you should be able to read about these and other solutions to your problem.

Good luck!

5. Established Member
Join Date
Jan 2007
Posts
344

## iteration problem

Indeed , close approaches need special attention . Be sure to adapt eventually your timestep at close encounters , if not the velocities will grow too much .

If you use the Newton approach also be aware to implement the iteration formula correctly as in the following example for the case of 1 body :
( pay attention to the subscripts 0=old and 1=new )

Distance now : r0=(x0^2+y0^2)^0.5
> a0=-g*M/r0/r0
> ax0=x0*a0/r0
> ay0=y0*a0/r0
New velocity :
vx1=vx0+ax0*tsim
vy1=vy0+ay0*tsim
New position
x1=x0+vx1*tsim
y1=y0+vy1*tsim
Then : next iteration
x0=x1
y0=y1
vx0=vx1
vy0=vy1
r0=SQR(x0^2+y0^2)
......

This iteration formula should work at appropriate timesteps . Mixing the indexes 0 and 1 in other ways gives false results .

IIRC this item has been discussed earlier in this forum . IIRC celestial mechanic came with other iteration formulas (of second order ) while the above iteratioin is of first order .

Good luck!

6. An education in every bowl o' BAUT Toasties. I tell you true.
Last edited by BigDon; 2009-Oct-15 at 07:12 PM. Reason: spelin'

7. Established Member
Join Date
Mar 2007
Posts
2,018
I've run into a similar problem in the one I was working on. I was able to mitigate it quite a bit by using the object's relativistic momentum instead of its mass to work out accelerations, but it's still a major problem. Giving them a volume in order to keep their centers of mass from getting too close also helped.

I think the biggest problem is that it's never going to be perfect if I keep using a somewhat minimalist numerical technique. Stupendous Man hit on my thinking - as the objects are falling toward each other, the distance they move in a single tick can get very large. The speed should come back down as they recede from each other, but if they're already moving quickly then they might skip so far past each other in the next tick that the deceleration ends up being too small to counteract it.

I'm guessing that it can work the other way, too, so that the total momentum of the system ends up decreasing over the course of the pass, but I haven't tried to prove it and it doesn't seem to be nearly as disruptive from a qualitative perspective.

I don't think I really need to bother with having gravity propagate at the speed of light instead of instantaneously. The solution I'm leaning toward is to break down and either make the length of a 'tick' variable for each object, based on the magnitude of the net force it's experiencing. That or I might try integrating over the length of a tick to get a continuous solution for near passes. Whichever I decide will be less of a hassle, probably.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•
here