N Body simulation
Ashish
I have been desperately trying to implement the NBody simulation. Can
someone give me an example of the masses and the initial velocities
(vx and vy) for the bodies and the iteration time so that I get a
pretty picture of the bodies moving at a nice pace (and not just
sitting there or shooting like bullets)
Thanks in advance
-Ashish
p.s. I have written the program for simulation. If you want I can give
you the link.
Ashish
Ashish
"Ashish" <ash...@hotmail.com> wrote in message news:aov0b7$mi4$1...@paperboy.it.wmich.edu...
Paul Schlyter
Ashish <ash...@hotmail.com> wrote:
> I have been desperately trying to implement the NBody simulation. Can
> someone give me an example of the masses and the initial velocities
> (vx and vy) for the bodies and the iteration time so that I get a
> pretty picture of the bodies moving at a nice pace (and not just
> sitting there or shooting like bullets)
contains C code for an accurate N-body simulator plus masses, initial
positions and velocities for the planets for two different dates.
So by integrating from one date to the other, you can check the
accuracy of your integration.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se
WWW: http://hem.passagen.se/pausch/index.html
http://home.tiscali.se/~pausch/
Ashish
"Paul Schlyter" <pau...@saaf.se> wrote in message
news:ap051a$14d3$1...@merope.saaf.se...
> In article <a1f45e0d.02102...@posting.google.com>,
> Ashish <ash...@hotmail.com> wrote:
>
> > I have been desperately trying to implement the NBody simulation. Can
> > someone give me an example of the masses and the initial velocities
> > (vx and vy) for the bodies and the iteration time so that I get a
> > pretty picture of the bodies moving at a nice pace (and not just
> > sitting there or shooting like bullets)
>
> Do a web search for DE118I.ZIP and download that archive. It
> contains C code for an accurate N-body simulator plus masses, initial
> positions and velocities for the planets for two different dates.
> So by integrating from one date to the other, you can check the
> accuracy of your integration.
Thanks a lot for the info, Paul.
-Ashish
Manfred Toplic
"Ashish" <ash...@hotmail.com> wrote in
news:a1f45e0d.02102...@posting.google.com...
Hello !
There is also another program for numerical integration available on
simtel.net. It's called "SOLEX7F5" and fits the DE200 and DE406
models from JPL.
http://www.simtel.net/pub/pd/16309.html
Manfred Toplic
Member of the *Astronomical Society of Carinthia*
Klagenfurt, Austria (N 46 36 50, E 14 19 03)
E-Mail: manfred...@aon.at
WWW: <http://privat.schlund.de/T/ToplicM/index.html>
jsc...@nospampirl.lpl.arizona.edu
: Sorry to bother you guys again, but is this group appropriate for
: there another group that you can suggest me?
: -Ashish
Well, posts on software simulations of celestial bodies is certainly
much more appropriate in this newsgroup than posts by Nancy and her
nitwit followers, or astrological posts, or claims of fake moonlandings.
Keep up the discussion, it's actually on-topic and an interesting one!
Jim.
Jim Scotti
Lunar & Planetary Laboratory jsc...@pirl.lpl.arizona.edu
University of Arizona
Tucson, AZ 85721 USA http://www.lpl.arizona.edu/~jscotti/
John Ladasky
Yes, N-body simulations are a wonderful topic for sci.astro.
At one time or another, most of us with some programming skill and an
interest in astronomy have tried to write a gravity simulation
program. If you were like me, your first program was terribly
inaccurate. I wrote my first one in high school, and I couldn't get
my virtual Earth to orbit the virtual Sun more than a few times before
Earth was flung out of the Solar System.
The problem, of course, is attempting to implement a continuous
function in a series of discrete steps. It is impossible to conserve
energy and angular momentum perfectly. Usually, at least when one is
just starting, one computes an acceleration vector for the object at
time 0, and then assumes a constant acceleration from t0 to t1.
Eventually, one gets around to implementing variable time increments,
so that when two objects get close to each other, the angles that the
objects subtend can be kept smaller. This helps, but at finer scales
and longer run times it doesn't help enough.
Something that I read (don't ask me what) inspired me to try an
iterative averaging method. I computed an initial acceleration
vector, a0, for t0. Using a0 I did a trial move to t1. Then I
computed an acceleration vector, a1, at the trial t1. But for the
real move of the object I averaged the a0 and a1. This helped a lot
with angular momentum problems, and it is intutively obvious why it
does.
I saw a professional gravity simulation running once that used
Runge-Kutta differential approximations, as apparently all of the
professional programs do. Runge-Kutta methods are apparently a
superset of what I did by averaging the two gravitational vectors, and
are even better. They take weighted averages of multiple trial moves
of the object. I was very impressed with the smooth, fast result.
Obviously, I would prefer to use Runge-Kutta methods. The problem
that I have (stop me if any of you suffer from this!) is that I like
to understand any code that I write. And Runge-Kutta methods are
awfully non-intuitive, though they clearly have a lot to offer in
terms of improved accuracy. So, I ask you: where, in your opinion,
can you find a GOOD explanation of how these methods work? A
discussion that passes through the naive stepwise method, through
something like my averaging method, and then finally to higher-order
methods would be ideal.
--
John J. Ladasky Jr., Ph.D.
Department of Biology
Johns Hopkins University
Baltimore MD 21218
USA
Earth
Greg Neill
news:c09b237b.02102...@posting.google.com...
> Obviously, I would prefer to use Runge-Kutta methods. The problem
> that I have (stop me if any of you suffer from this!) is that I like
> to understand any code that I write. And Runge-Kutta methods are
> awfully non-intuitive, though they clearly have a lot to offer in
> terms of improved accuracy. So, I ask you: where, in your opinion,
> can you find a GOOD explanation of how these methods work? A
> discussion that passes through the naive stepwise method, through
> something like my averaging method, and then finally to higher-order
> methods would be ideal.
A book that I can recommend is J.M.A. Danby's "Computer Modelling:
From Sports to Spaceflight..From Order to Chaos". It has a
pretty good introduction to RK methods, including a flowchart
and FORTRAN code for a very robust variant, the Runge Kutta
Fehlberg method. The rest of the book is an excellent romp
through all manner of real-world simulations.
Ashish
>
> Yes, N-body simulations are a wonderful topic for sci.astro.
It sure is!
>
> At one time or another, most of us with some programming skill and an
> interest in astronomy have tried to write a gravity simulation
> program. If you were like me, your first program was terribly
> inaccurate. I wrote my first one in high school, and I couldn't get
You are so right. Although I am a good programmer, I dont think I am so good
at astronomy. My first program is so wrong that bodies keep on flying all
over the screen. But the point of doing that assignment is to compute the
time complexities of the algorithms rather than the actual simulation :-)
So, the purpose is achieved.
> my virtual Earth to orbit the virtual Sun more than a few times before
> Earth was flung out of the Solar System.
>
> The problem, of course, is attempting to implement a continuous
> function in a series of discrete steps. It is impossible to conserve
> energy and angular momentum perfectly. Usually, at least when one is
> just starting, one computes an acceleration vector for the object at
> time 0, and then assumes a constant acceleration from t0 to t1.
That seems to be the problem in my case too. The bodies slowly move towards
each other, and when they are too close, they shoot in the opposite
directions like bullets.
Brr... looks scary. I'll leave all those complex algorithms to you gurus :-)
> --
> John J. Ladasky Jr., Ph.D.
> Department of Biology
> Johns Hopkins University
> Baltimore MD 21218
> USA
> Earth
-Ashish
Paul Schlyter
John Ladasky <lad...@my-deja.com> wrote:
> I saw a professional gravity simulation running once that used
> Runge-Kutta differential approximations, as apparently all of the
> professional programs do.
> Runge-Kutta methods are apparently a superset of what I did by
> averaging the two gravitational vectors, and are even better.
> They take weighted averages of multiple trial moves of the object.
> I was very impressed with the smooth, fast result.
too slow... :-)
For instance, check out the contents on the file DE118I.ZIP
(available at any SimTel mirror as well as on a lot of other places;
doing a web search of DE118I.ZIP will give you lots of hits). Steve
Moshier's DE118I package uses Runge-Kutta to start up the integration
but then switches to Adams-Moulton, since Adams-Moulton is some 10
times faster! "But why does he use Runge-Kutta at all, why doesn't
he use Adams-Moulton all the time?" I hear you ask. Because
Adams-Moulton requires a number of available integration steps right
from the start (the actual number of steps required depends on the
order selected for the Adams-Moulton integration), while Runge-Kutta
can start from just a series of position and velocity vectors at just
one instant.
> Obviously, I would prefer to use Runge-Kutta methods. The problem
> that I have (stop me if any of you suffer from this!) is that I like
> to understand any code that I write. And Runge-Kutta methods are
> awfully non-intuitive, though they clearly have a lot to offer in
> terms of improved accuracy. So, I ask you: where, in your opinion,
> can you find a GOOD explanation of how these methods work? A
> discussion that passes through the naive stepwise method, through
> something like my averaging method, and then finally to higher-order
> methods would be ideal.
I enjoy "Numerical Methods" by Dahlquist-Bjork (Prentice-Hall 1974;
ISBN 0-13-627315-7) a lot, but there should be many other books to
choose from as well. Check out a good library, or check out Amazon
at:
http://www.amazon.com/exec/obidos/ASIN/0136273157/104-6506615-2686321
There is also a similar book, available online, also by Dahlqvist
and Bjork, titled "Numerical Mathematics and Scientific Computation",
at:
http://www.mai.liu.se/~akbjo/NMbook.html
Check out the charpter "Ordinary differential equations"
John Ladasky
> "John Ladasky" <lad...@my-deja.com> wrote in message
> news:c09b237b.02102...@posting.google.com...
> > Hi there --
> >
> > Yes, N-body simulations are a wonderful topic for sci.astro.
>
> It sure is!
>
> >
> > At one time or another, most of us with some programming skill and an
> > interest in astronomy have tried to write a gravity simulation
> > program. If you were like me, your first program was terribly
> > inaccurate. I wrote my first one in high school, and I couldn't get
>
> You are so right. Although I am a good programmer, I dont think I am so good
> at astronomy. My first program is so wrong that bodies keep on flying all
> over the screen. But the point of doing that assignment is to compute the
> time complexities of the algorithms rather than the actual simulation :-)
> So, the purpose is achieved.
What do you mean by "time complexities"? Do you mean the amount of
processing time, as a function of the number of simulated objects? Or
something else?
> > my virtual Earth to orbit the virtual Sun more than a few times before
> > Earth was flung out of the Solar System.
> >
> > The problem, of course, is attempting to implement a continuous
> > function in a series of discrete steps. It is impossible to conserve
> > energy and angular momentum perfectly. Usually, at least when one is
> > just starting, one computes an acceleration vector for the object at
> > time 0, and then assumes a constant acceleration from t0 to t1.
>
> That seems to be the problem in my case too. The bodies slowly move towards
> each other, and when they are too close, they shoot in the opposite
> directions like bullets.
They both get a large acceleration vector that you apply for a
*finite* time when, in reality, any acceleration vector applies for an
infinitely short time. You violate conservation of energy.
I mentioned the first and, for the beginner, the most important
solution to this problem in the paragraph that you quote immediately
afterwards:
> > Eventually, one gets around to implementing variable time increments,
> > so that when two objects get close to each other, the angles that the
> > objects subtend can be kept smaller. This helps, but at finer scales
> > and longer run times it doesn't help enough.
Here's that algorithm in more detail. Note the position of your
objects at t0. Compute a trial move to t1. Look at the angles that
the objects subtended relative to each other. If any of those angles
exceed a certain value, say 0.02 radians, go back to t0. *Cut your
time increment in half.* Repeat the moves. Continue using this
smaller time increment until an angle exceeds 0.02 radians again, in
which case you cut the time increment in half again; or, if all angles
should fall below 0.01 radian, you may double the time increment.
If you want a live display of your data, you may need to queue up
several data points, and flush them according to a clock.
Yes, this will get very inefficient with many objects. But it is
something that is intuitive for the programmer.
> > Something that I read (don't ask me what) inspired me to try an
> > iterative averaging method. I computed an initial acceleration
> > vector, a0, for t0. Using a0 I did a trial move to t1. Then I
> > computed an acceleration vector, a1, at the trial t1. But for the
> > real move of the object I averaged the a0 and a1. This helped a lot
> > with angular momentum problems, and it is intutively obvious why it
> > does.
> >
> > I saw a professional gravity simulation running once that used
> > Runge-Kutta differential approximations, as apparently all of the
> > professional programs do. Runge-Kutta methods are apparently a
> > superset of what I did by averaging the two gravitational vectors, and
> > are even better. They take weighted averages of multiple trial moves
> > of the object. I was very impressed with the smooth, fast result.
> >
> > Obviously, I would prefer to use Runge-Kutta methods. The problem
> > that I have (stop me if any of you suffer from this!) is that I like
> > to understand any code that I write. And Runge-Kutta methods are
> > awfully non-intuitive, though they clearly have a lot to offer in
> > terms of improved accuracy. So, I ask you: where, in your opinion,
> > can you find a GOOD explanation of how these methods work? A
> > discussion that passes through the naive stepwise method, through
> > something like my averaging method, and then finally to higher-order
> > methods would be ideal.
> >
>
> Brr... looks scary. I'll leave all those complex algorithms to you gurus :-)
Hey, I'm a biologist, how hard can it be? :^)
I think that you can certainly implement my iterating average method
without too much difficulty.
John Ladasky
recommendations.
pau...@saaf.se (Paul Schlyter) wrote in message news:<ap859q$qi0$1...@merope.saaf.se>...
> In article <c09b237b.02102...@posting.google.com>,
> John Ladasky <lad...@my-deja.com> wrote:
>
> > I saw a professional gravity simulation running once that used
> > Runge-Kutta differential approximations, as apparently all of the
> > professional programs do.
>
> Not as the main integrator though but only as a "start-up". See below.
>
> > Runge-Kutta methods are apparently a superset of what I did by
> > averaging the two gravitational vectors, and are even better.
> > They take weighted averages of multiple trial moves of the object.
> > I was very impressed with the smooth, fast result.
>
> The reason Runge-Kutta isn't used as the main integrator is that it's
> too slow... :-)
Well, for those of us who are just trying to get the Earth, Sun, and
Moon to behave correctly, on a time scale that would accurately
predict solar and lunar eclipses over approximately one human
lifetime, speed is probably irrelevant. Any algorithm, even a
ninth-order RK, would be blindingly fast on a modern CPU. (I wrote my
first gravity simulator on a 1.0 MHz Apple II. Because I was a
novice, I was even using an interpreted language, BASIC, rather then a
compiled language. Talk about slow.) The speed of the computation
scales roughly with the inverse square of the number of objects.
> For instance, check out the contents on the file DE118I.ZIP
> (available at any SimTel mirror as well as on a lot of other places;
> doing a web search of DE118I.ZIP will give you lots of hits). Steve
> Moshier's DE118I package uses Runge-Kutta to start up the integration
> but then switches to Adams-Moulton, since Adams-Moulton is some 10
> times faster!
I downloaded exactly this file a few years ago, and I couldn't figure
out what the code was supposed to do. Now that you have explained it,
maybe I will understand the details of the code better. Thanks!
> "But why does he use Runge-Kutta at all, why doesn't
> he use Adams-Moulton all the time?" I hear you ask. Because
> Adams-Moulton requires a number of available integration steps right
> from the start (the actual number of steps required depends on the
> order selected for the Adams-Moulton integration), while Runge-Kutta
> can start from just a series of position and velocity vectors at just
> one instant.
That makes sense. One method is ab initio, the other is extrapolated.
You know, if you need to run N-body simulations for HUGE numbers of
objects, you don't do it all in software. There are systems which
implement just the repetitive gravity computations in programmable
logic. The algorithm is implemented in hardware using an architecture
that is massively parallel, very unlike that of a general-purpose CPU.
Check out this web page for one example:
http://www.research.ibm.com/grape/
Ashish
Yep, thats what I meant. Processing time as a function of n.
I would definetely implement it, but not for my assignment. Because if I do
that I would get an F on the assignment :). For this assignment, we are
supposed to calculate the time complexities of 3 different algorithms (The
one that I mentioned above, one using quad trees and one using recursive
bisection method)
Thanks though.
Not impossible for sure, I can implement it. But too little time :(
--
-Ashish
--------------------------------------------------------------------------
Hi! I'm a shareware signature! Send $5 if you use me, send $10 for manual!
http://www.123ashish.com
Bob Jenkins
> I have been desperately trying to implement the NBody simulation. Can
> someone give me an example of the masses and the initial velocities
> (vx and vy) for the bodies and the iteration time so that I get a
> pretty picture of the bodies moving at a nice pace (and not just
> sitting there or shooting like bullets)
Try:
object 1: mass 1, position (0,0), velocity (0,0)
object 2: mass 0, position (1,0), velocity (0,1)
Here's a nice time step formula named "leapfrog" (p = position, v =
velocity, a = acceleration from gravity at current position, t = time
step):
loop over all objects i
v[i] = v[i] + a[i]*t;
loop over all objects i
p[i] = p[i] + v[i]*t;
Adjust v[i] to v[i] - a[i]*t/2 before you begin, because the time step
formula assumes the velocities are actually measured halfway between
positions.
You could have found this yourself without asking anyone by searching
for "orbit applet" on the web until you found one that worked and had
source code, then examining the source code.
Ashish
"Bob Jenkins" <bob_j...@burtleburtle.net> wrote in message
news:a5d787df.02102...@posting.google.com...
> "Ashish" <ash...@hotmail.com> wrote in message
news:<aov44u$nk1$1...@paperboy.it.wmich.edu>...
>
> > I have been desperately trying to implement the NBody simulation. Can
> > someone give me an example of the masses and the initial velocities
> > (vx and vy) for the bodies and the iteration time so that I get a
> > pretty picture of the bodies moving at a nice pace (and not just
> > sitting there or shooting like bullets)
>
> Try:
>
> object 1: mass 1, position (0,0), velocity (0,0)
> object 2: mass 0, position (1,0), velocity (0,1)
>
mass = 0???
The force would be zero then
Greg Neill
>
> "Bob Jenkins" <bob_j...@burtleburtle.net> wrote in message
> news:a5d787df.02102...@posting.google.com...
> > "Ashish" <ash...@hotmail.com> wrote in message
> news:<aov44u$nk1$1...@paperboy.it.wmich.edu>...
> >
> > > I have been desperately trying to implement the NBody simulation.
Can
> > > someone give me an example of the masses and the initial velocities
> > > (vx and vy) for the bodies and the iteration time so that I get a
> > > pretty picture of the bodies moving at a nice pace (and not just
> > > sitting there or shooting like bullets)
> >
> > Try:
> >
> > object 1: mass 1, position (0,0), velocity (0,0)
> > object 2: mass 0, position (1,0), velocity (0,1)
> >
>
> mass = 0???
> The force would be zero then
Ah, but you're not calculating force, you're calculating
acceleration.
F = G*M1*M2/r^2 ==> a = G*M1/r^2
M2 will accelerate due to M1, but not vice versa since M2
is negligible.