Solar System simulation?

55 views
Skip to first unread message

trojanfoe

unread,
Mar 24, 2011, 6:10:45 AM3/24/11
to Gravit mailing list
Hi there - I found Gravit when looking for an open source alternative
to Universe Sandbox and I think Gravit looks fantastic. Do you have
any plans to include the ability to simulate solar systems, and be
able to play with them by moving planets around to observe the
effect? I think Gravit has alot of potential but hasn't be updated
for over 6 years - do you have plans to enhance it?

Best Regards,
Andy Duplain

Gerald Kaszuba

unread,
Mar 24, 2011, 6:45:01 AM3/24/11
to gra...@googlegroups.com, trojanfoe
Hi Andy,

On Thursday, March 24, 2011 9:10:45 PM UTC+11, trojanfoe wrote:
Do you have
any plans to include the ability to simulate solar systems, and be
able to play with them by moving planets around to observe the
effect?
 
A while ago I tried to create our solar system in Gravit, but it wasn't very successful. The orbits just went haywire. I unfortunately didn't spend much time investigating the problem.

I think Gravit has alot of potential but hasn't be updated 
for over 6 years - do you have plans to enhance it?

I recently did some work on it for putting on the Mac App Store. You can see the changes on the github account: https://github.com/gak/gravit

There are plans for doing more work on it, including more interaction with the simulation.

If you want to experiment with your own simulations, you can write your own spawn scripts. Check out http://gravit.slowchop.com/docs/SpawnScripting.php if you're interested.

Gerald

--

trojanfoe

unread,
Mar 24, 2011, 9:02:25 AM3/24/11
to Gravit mailing list
On Mar 24, 10:45 am, Gerald Kaszuba <gerald.kasz...@gmail.com> wrote:
> Hi Andy,
>
> On Thursday, March 24, 2011 9:10:45 PM UTC+11, trojanfoe wrote:
>
> > Do you have
> > any plans to include the ability to simulate solar systems, and be
> > able to play with them by moving planets around to observe the
> > effect?
>
> A while ago I tried to create our solar system in Gravit, but it wasn't very
> successful. The orbits just went haywire. I unfortunately didn't spend much
> time investigating the problem.
>
> I think Gravit has alot of potential but hasn't be updated
>
> > for over 6 years - do you have plans to enhance it?
>
> I recently did some work on it for putting on the Mac App Store. You can see
> the changes on the github account:https://github.com/gak/gravit
>
> There are plans for doing more work on it, including more interaction with
> the simulation.
>
> If you want to experiment with your own simulations, you can write your own
> spawn scripts. Check outhttp://gravit.slowchop.com/docs/SpawnScripting.php
> if you're interested.


Great stuff many thanks. I had been working with 0.4.2 and had to
make a few changes to 'configure' and lua.c in order to get to compile
and work under Fedora 14. If I start working with the github version
are you interested in feedback/diffs required to get it working on
this platform?

Andy Duplain

Gerald Kaszuba

unread,
Mar 24, 2011, 3:43:02 PM3/24/11
to gra...@googlegroups.com, trojanfoe

I had been working with 0.4.2 and had to 
make a few changes to 'configure' and lua.c in order to get to compile
and work under Fedora 14.  If I start working with the github version
are you interested in feedback/diffs required to get it working on
this platform?

Of course! I welcome any patches. github pull requests are even better :)

Romeo Van Snick

unread,
Mar 24, 2011, 6:00:14 PM3/24/11
to gra...@googlegroups.com
Hi Gerald, 

may I ask you remove me from the mailing list?

I get full inboxes from all these emails I don't actually read.. 

thanks,
Romeo


--
You received this message because you are subscribed to the Google Groups "Gravit mailing list" group.
To post to this group, send email to gra...@googlegroups.com.
To unsubscribe from this group, send email to gravit+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gravit?hl=en.

Frank M.

unread,
Apr 20, 2011, 7:33:05 AM4/20/11
to Gravit mailing list
Hi Gerald, nice to hear that you are still maintaining gravit.


Problems with the solar system: I once tried to understand your
physics algorithm, and saw that the accelerations you compute (between
two particles) are wrongly dependant on the mass of _both_ particles.
The result is, that two particles will always try to spin around their
geometric center. In our solar system, this means that sun and earth
would try to rotate around each other. Maybe that's the reason you
could not model the solar system.

Seems you invented a way to cancel the inertia of masses, and build
some really nice looking around this :-))

I think that fixing the problem would mean big changes to all spawn
scipts, which are written for the current "inertia-less" physics
implementation.


Frank.

On 24 Mrz., 12:45, Gerald Kaszuba <gerald.kasz...@gmail.com> wrote:
> A while ago I tried to create our solar system in Gravit, but it wasn't very
> successful. The orbits just went haywire. I unfortunately didn't spend much
> time investigating the problem.
>
>
> There are plans for doing more work on it, including more interaction with
> the simulation.
>
> If you want to experiment with your own simulations, you can write your own
> spawn scripts. Check outhttp://gravit.slowchop.com/docs/SpawnScripting.php

Gerald Kaszuba

unread,
Apr 20, 2011, 6:02:06 PM4/20/11
to gra...@googlegroups.com
On 20 April 2011 21:33, Frank M. <frank....@btc-ag.com> wrote:
I once tried to understand your
physics algorithm, and saw that the accelerations you compute (between
two particles) are wrongly dependant on the mass of _both_ particles.
The result is, that two particles will always try to spin around their
geometric center.

Interesting to find this out. I guess Open Source is good for spotting obvious flaws like this.

I'll investigate and fix it before the next release :)

Roberto Sanchez

unread,
Apr 21, 2011, 3:15:41 PM4/21/11
to gra...@googlegroups.com
Don't they revolve around each other though? From Wikipedia:

When a moon orbits a planet, or a planet orbits a star, both bodies are actually orbiting around a point that lies outside the center of the primary (the larger body).

http://en.wikipedia.org/wiki/Barycenter



--
Roberto Sanchez


On Apr 20, 2011 5:32 PM, Frank M. <frank....@btc-ag.com> wrote:

Hi Gerald, nice to hear that you are still maintaining gravit.


Problems with the solar system: I once tried to understand your
physics algorithm, and saw that the accelerations you compute (between
two particles) are wrongly dependant on the mass of _both_ particles.
The result is, that two particles will always try to spin around their
geometric center. In our solar system, this means that sun and earth
would try to rotate around each other. Maybe that's the reason you
could not model the solar system.

Seems you invented a way to cancel the inertia of masses, and build
some really nice looking around this :-))

I think that fixing the problem would mean big changes to all spawn
scipts, which are written for the current "inertia-less" physics
implementation.


Frank.

On 24 Mrz., 12:45, Gerald Kaszuba <gerald.kasz...@gmail.com> wrote:
> A while ago I tried to create our solar system in Gravit, but it wasn't very
> successful. The orbits just went haywire. I unfortunately didn't spend much
> time investigating the problem.
>
>
> There are plans for doing more work on it, including more interaction with
> the simulation.
>
> If you want to experiment with your own simulations, you can write your own
> spawn scripts. Check outhttp://gravit.slowchop.com/docs/SpawnScripting.php
> if you're interested.
>
> Gerald

trojanfoe

unread,
Apr 22, 2011, 5:05:51 AM4/22/11
to Gravit mailing list
I'm just getting into all this, and don't know the maths involved, but
I do know that the Moon does have an effect on the Earth's orbit
(making it appear to hop around its orbit, rather than move smoothly)
so surely the mass of the Moon plays a part when calculating the
Earth's acceleration?

-A

On Apr 21, 8:15 pm, Roberto Sanchez <rsanchez1...@gmail.com> wrote:
> Don't they revolve around each other though? From Wikipedia:
>
> When a moon orbits a planet, or a planet orbits a star, both bodies are
> actually orbiting around a point that lies outside the center of the primary
> (the larger body).
>
> http://en.wikipedia.org/wiki/Barycenter
>
> --
> Roberto Sanchez
>
> ------------------------------

Gerald Kaszuba

unread,
Apr 22, 2011, 8:41:47 AM4/22/11
to gra...@googlegroups.com
If you want to take a look, the code in question is at https://github.com/gak/gravit/blob/master/frame-pp.c#L66

More specifically, line 55 to 70.

Gerald


On 22 April 2011 19:05, trojanfoe <troj...@gmail.com> wrote:
I'm just getting into all this, and don't know the maths involved, but
I do know that the Moon does have an effect on the Earth's orbit
(making it appear to hop around its orbit, rather than move smoothly)
so surely the mass of the Moon plays a part when calculating the
Earth's acceleration?

Frank M.

unread,
Apr 22, 2011, 9:08:28 AM4/22/11
to Gravit mailing list
Right, of course the moon and earth attarct each other, and so they
have an influence one each other's orbit.
I wanted to say that with the current impementation, both objects get
the same orbit velocity, which means that
they will orbit around the geometric center of the earth-moon system.

Gravit currently does something like this:

* for all particle pars,
1. compute the force between them with F=G * m1 * m2 /
sqrt(distance)
2. add the force to the velocity: vel = vel + F * vector(distance)

* advance all particles:
new position = old position + velocity.

The problem is step 2, where the velocity is increased by the force F.


Remember that F=m1 *a, and v= a * t ; so v = t * F/m1 (v:
velocity, a: accelration, m1: particles's mass)

We can savely assume t=1 (simulation step time).
As we deal with vectors here,vel_new must be in the same direction as
the distance vector; this means we need to normailize the distance
vector fist (to length = 1) and then multiply.

This means gravit should calculate
1. vel_new = G * m2 / sqrt(distance)
2. vel = vel + vel_new * vector_normalized(distance)


(There are some possible optimizations when implementing this in
gravit...)

best regards,
Frank.

Benjamin Brink

unread,
Apr 22, 2011, 12:06:40 PM4/22/11
to gra...@googlegroups.com
Gerald,

The calculations should resemble how the N-body problem is solved:

http://en.wikipedia.org/wiki/N-body_problem

Basically, for each iteration of time,

the influence on all the N number of bodies are calculated by

choosing each body in succession,

determining the individual influence (force) of each of the remaining
bodies on it individually,

then adding the individual force vectors into one force vector.

Once all the force vectors have been calculated for the N bodies,

the force vector for body 1 is applied to body 1.. the force vector for
body 2 is applied to body 2 etc..

and then the time interval is iterated.

Importantly, the new position of each body is not applied, until all the
bodies new positions have been calculated. Another way to say this,
each calculation within an interval uses the same body parameters
(position, mass and other values) of the same interval, before applying
the influences.

The 2-body solution is the n-body solution for 2 bodies.

Since there are only 2 bodies, calculating the influence of one body on
the other N-1 objects is the same as calculating the influence of the
other body.

The 3-body solution is the n-body solution for 3 bodies.

Since there are only 3 bodies, calculating the influence of one body on
the other N-1 objects consists of 2 sets of calculations on the one
body. That is, one set of calculations for each of the 2 remaining bodies.

A 12-body solution is the n-body solution for 12 bodies.

Since there are 12 bodies, calculating the influence of one body on the
other N-1 objects consists of 11 sets of calculations on the one body.
That is, one set of calculations for each of the 11 remaining bodies.

As the number of bodies increase, the number of calculations increase
exponentially:

body count, calculations
1 , 0
2 , 1
3 , 3 iterations, 1 for each body * 2 other bodies = 6
12 , 12 iterations, 1 for each body * 11 other bodies = 132
100 , 100 iterations, 1 for each body * 99 other bodies = 9900
N, N * (N - 1 )

Which makes the entire calculation process slow down considerably with
many bodies.

So, there are numerical shortcuts that can be made to give best
approximations.

One method is to calculate the center of gravity (and combined mass) for
all bodies, and then subtract the influence of the object that is
currently being calculated for each body, before calculating the forces
on the body.

So for a N body system, for each iteration of time, the center of
gravity of the system is calculated first (that's a set of N calculations)

Then the influence for each of the N bodies is calculated separately, by:

iterating through each of the N bodies. Call it P for following example.

first subtracting P's influence on the center of gravity of N, which
becomes the center of gravity of a particular set of (N-1) bodies. Maybe
call them N-P to indicate their uniqueness?

then calculating the influence of the center of gravity of the N-P on P.

Once the iterations are complete for determining the influences on all N
bodies, then the positions are updated for the N bodies.

This process makes the numerical calculations increase almost linearly
with the number of bodies:

1 , 0
2 , 1 + 1 + 1
3 , 2 + 1 + 1
12, 11 + 1 + 1
100, 99 + 1 + 1
N, N-1 + 1 set for (N-P) + P or N + 1 sets of calculations.

If you carefully track your calculations, you will see patterns that
will allow you to remove redundant calculations and ones that are not
significant.

cheers,

Benjamin

Gerald Kaszuba wrote:
> If you want to take a look, the code in question is at
> https://github.com/gak/gravit/blob/master/frame-pp.c#L66
>
> More specifically, line 55 to 70.
>
> Gerald
>
> On 22 April 2011 19:05, trojanfoe <troj...@gmail.com

> <mailto:troj...@gmail.com>> wrote:
>
> I'm just getting into all this, and don't know the maths involved, but
> I do know that the Moon does have an effect on the Earth's orbit
> (making it appear to hop around its orbit, rather than move smoothly)
> so surely the mass of the Moon plays a part when calculating the
> Earth's acceleration?
>
>
> --
> Gerald Kaszuba
> http://geraldkaszuba.com/
> http://twitter.com/gakman/
>

Benjamin Brink

unread,
Apr 22, 2011, 4:24:03 PM4/22/11
to Gravit mailing list
(reposting via web, as apparently my direct email didn't make it here)

Gerald,

The calculations should resemble how the N-body problem is solved:

http://en.wikipedia.org/wiki/N-body_problem

Basically, for each iteration of time,

the influence on all the N number of bodies are calculated by

1. choosing each body in succession,

2. determining the individual influence (force) of each of the
remaining bodies on it individually,

3. then adding the individual force vectors into one force vector.

4. Once all the force vectors have been calculated for the N bodies,

5. the force vector for body 1 is applied to body 1.. the force vector
for body 2 is applied to body 2 etc..

and then the time interval is iterated.

Importantly, the new position of each body is not applied, until all
the bodies new positions have been calculated. Another way to say
this, each calculation within an interval uses the same body
parameters (position, mass and other values) of the same interval,
before applying the influences.

The 2-body solution is the n-body solution for 2 bodies.

Since there are only 2 bodies, calculating the influence of one body
on the other N-1 objects is the same as calculating the influence of
the other body.

The 3-body solution is the n-body solution for 3 bodies.

Since there are only 3 bodies, calculating the influence of one body
on the other N-1 objects consists of 2 sets of calculations on the one
body. That is, one set of calculations for each of the 2 remaining
bodies.

A 12-body solution is the n-body solution for 12 bodies.

Given a 12-body problem, there are 12 bodies, calculating the
On Apr 22, 5:41 am, Gerald Kaszuba <gerald.kasz...@gmail.com> wrote:
> If you want to take a look, the code in question is athttps://github.com/gak/gravit/blob/master/frame-pp.c#L66
>
> More specifically, line 55 to 70.
>
> Gerald
>

Emanuel Larsson

unread,
Apr 23, 2011, 4:28:34 AM4/23/11
to gra...@googlegroups.com
Hi,

I would really like a detailed step by step walkthru to install a compiler, import Gravit source code, get the necessary libraries etc, include them and then finally compile. It would have to be as to a complete beginner. So if you think you could do this please write me. Personally might be better. (I have had some ideas I wanted to try to implement as for example using a timer to save simulation and screenshot with automatically generated name/timestamp.)

Emanuel

Frank M.

unread,
Apr 23, 2011, 1:50:48 PM4/23/11
to Gravit mailing list
Hi Benjamin,

your ideas is interesting, but i think using a single center of
gravity is too much abstraction, at least for the general n-body
problem.

Just imagine we have two galaxies. Stars in each galaxy should rotate
around each other (binaries), around a local group, and around their
galactic center.
If i follow your idea, there will be one center of gravity. As all
individual stars are relatively light, the center should not change a
lot when i substract the effect of a single star. This means, they
would basicially rotate around this one center, or simply collaps into
this one point.


The algorithms I have heard about are all more complicated tham yours,
but probably use a similar idea. The barnes-hutt octtree approach is
using a hierarchy of center-of-gravity points, and selects them by a
distance-based criterion. It has O(n * log n). Then there is something
called the "fast multipole method", which includes a fourier
transform, and is said to have O(n) complexity.

Something similar to your idea is actually used for treecodes with
different time steps (idea: close particles get updated very often,
and distant ones are updated less often). Here you would search for
close stars, and treat then as 2-body problem (if possible). Then you
compute their gravitational center (to go up one level in the spacial
hierarchy "tree"), and try to find partners on the same (or "right")
abstraction level, and apply 2-body again. Repeat this, going up in
the tree, until you reach the root node. Afterwards, walk down the
tree to add all "abstracted" accelerations to the particles down the
tree. This is sometimes cosidered as "inverse barnes-hutt (oct-
tree)".


cheers,
Frank.

Benjamin Brink

unread,
Apr 23, 2011, 2:30:51 PM4/23/11
to gra...@googlegroups.com
Hi Frank,

You're right.

The single center of gravity short-cut doesn't work for local bodies
with significant influence. Local bodies with significant influence
have to be calculated separately also, so instead of N-1, it's N-M,
where M is the number of bodies that have a significant influence on the
body in question. My post was quick, and working from a sad excuse for
a memory.

The center of gravity short-cut is a physical representation of caching
calculations. I'm glad to see Barnes-Hut has it all worked out:
http://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation
Looks like the External links section already has some C++
implementations that might be able to be adapted (with copyright vetting
and compliance.)

Anyway, there are various techniques one can employ to reduce the
overall calculation load for an N-body.

Whether sorting by proximity, or force, or a function dependent on force
and the net change of force over the last S iterations etc, the process
amounts to smartly adapting the iteration calculations to reduce the
overall calculation load.

Using some rounding, depending on significance needed to achieve
accuracy in the simulation (and not more accuracy than needed), a
programmer could add caching to a function by building a matrix or hash
of values, or even simplifying the equation in some cases, for example
by pre-mapping some parts of the calculation that are repeated more
frequently.

Hopefully, this helps inspire a smartly adapted solution for gravit.

cheers,

Benjamin

Reply all
Reply to author
Forward
0 new messages