Results 1 to 8 of 8

Thread: Help with a galaxy simulator (Gravity)

Hybrid View

  1. #1
    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?

    Any comments are welcome.
    Thanks!

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

  2. #2
    Join Date
    Aug 2003
    Location
    The Wild West
    Posts
    7,714
    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:

    Quote Originally Posted by Cyoor View Post
    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.
    Everyone is entitled to his own opinion, but not his own facts.

  3. #3
    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.

    Anyway.. Thanks for your answer.. =)

    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. #4
    Join Date
    Sep 2006
    Posts
    1,424

    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. 2009-Oct-15, 06:55 PM

  6. #6
    Join Date
    Jan 2007
    Posts
    345

    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 .
    In your case the universe in your box should oscillate then.

    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!

  7. #7
    Join Date
    Jul 2006
    Posts
    9,147
    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'
    Time wasted having fun is not time wasted - Lennon
    (John, not the other one.)

  8. #8
    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.

Similar Threads

  1. Orbit Gravity Simulator Assistance Required
    By DanThaiWang in forum Space/Astronomy Questions and Answers
    Replies: 11
    Last Post: 2011-Apr-01, 03:08 AM
  2. Gravity simulator
    By taa1 in forum Fun-n-Games
    Replies: 6
    Last Post: 2007-Apr-13, 12:15 AM
  3. Best 3-D solar system/galaxy simulator?
    By Wombaticus Rex in forum Space/Astronomy Questions and Answers
    Replies: 0
    Last Post: 2006-Sep-09, 06:13 PM
  4. Gravity Simulator...no, it's not artificial gravity...
    By Charlie in Dayton in forum Astronomy
    Replies: 1
    Last Post: 2005-Aug-03, 03:52 PM
  5. Gravity Simulator Program
    By tofu in forum Astronomy
    Replies: 3
    Last Post: 2005-Jul-19, 04:02 PM

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
The forum is sponsored in-part by: