PDA

View Full Version : Data on solar system

Alkatran
10th March 2006, 11:50 AM
I'm doing a small programming project at university: a simple gravity simulation of the sun, planets and our moon.

The program works alright, but I need to get correct data about the positions and speeds of the planets. I have managed to find all of the masses and diameters (easy), as well as the positions (which was more difficult to find).

What I'm still missing are the speeds. I could use the position data at different times to figure out the shape of the orbit and from that deduce the speed... but that seems like an awful lot of work someone else has already done.

Any good sources?

CFLarsen
10th March 2006, 11:54 AM
All here. (http://www.solarviews.com/eng/homepage.htm)

tracer
10th March 2006, 12:00 PM
If you know the semimajor axis of a planet's orbit, you can deduce its orbital speed (or at least its orbital period) directly, using Kepler's 3rd law (P^3 = A^2).

Of course, you want linear speed, not angular speed, so for that you'd have to know the orbit's eccentricity.

Alkatran
10th March 2006, 12:56 PM
All here. (http://www.solarviews.com/eng/homepage.htm)

Excellent, thanks!

CFLarsen
10th March 2006, 01:06 PM

JayT
10th March 2006, 02:53 PM
I'm doing a small programming project at university: a simple gravity simulation of the sun, planets and our moon.

The program works alright, but I need to get correct data about the positions and speeds of the planets. I have managed to find all of the masses and diameters (easy), as well as the positions (which was more difficult to find).

What I'm still missing are the speeds. I could use the position data at different times to figure out the shape of the orbit and from that deduce the speed... but that seems like an awful lot of work someone else has already done.

Any good sources?

Hi, Alkatran:

Are you a student of astronomy?
What programming language are you using for your project ?

Just curious, because I've been working on some high-precision astronomical computations that run on the Internet and thought I might be able to help.

Scientific computations are one of my specialties.

This is still a work in progress, but shows a small sample of the kind of stuff I do related to astronomy when nobody's watching.

http://www.neoprogrammics.com/astronomy/

If you haven't solved your problem yet, I'd like to know more details about exactly what you are trying to do.

:)

Alkatran
10th March 2006, 03:08 PM
It's just the end-of-term project for my computer simulations in science class. We had to pick an (obsenely easy) project to do. I thought showing off PV = nRT by moving a line up and down was a bit boring so I went with modelling the solar system.

One problem I'm having is the whole thing won't be very stable because I'm using a simple 'assume-force-constant-for-x-time-and-iterate' method. Any suggestions for something better? It calculates very quickly currently (time-step is set at one second and movement is discernable) but if I move the time step up...

Angus McPresley
11th March 2006, 03:29 PM
One problem I'm having is the whole thing won't be very stable because I'm using a simple 'assume-force-constant-for-x-time-and-iterate' method. Any suggestions for something better? It calculates very quickly currently (time-step is set at one second and movement is discernable) but if I move the time step up...

Ah yes, the old problem of simulating gravity in discrete steps.

The only real solution is to use calculus and differential equations, which is what astronomers do for all but the basest of simulations. That's probably more complex than you want to make this project, though.

I would have the students set up their simulations, but then when they occasionally notice planets flying off madly in different directions, have a discussion as to why this happened, and hint at the calculus solution, so that the more ambitious students can go off and explore that option on their own.

Alkatran
11th March 2006, 03:47 PM
Calculus solution? Doesn't that only work for two bodies?

If I ignore all the other planets the effect is negligable, but I assume that the discrepancy grows larger as time goes by.

Right now it looks great. I put code in to calculate the time-step based on the 'simulation time to real time' ratio you want. It speeds up the simulation when it's overshooting and slows it down otherwise.

Ziggurat
11th March 2006, 03:47 PM
One problem I'm having is the whole thing won't be very stable because I'm using a simple 'assume-force-constant-for-x-time-and-iterate' method. Any suggestions for something better? It calculates very quickly currently (time-step is set at one second and movement is discernable) but if I move the time step up...

Sounds like you're using what's referred to as Euler's method of integration (you're integrating the equations of motion over time). If you want a more sophisticated algorithm for doing this with less error, I would suggest a Runge-Kutta method. You can find out some info on the fourth-order version on Wikipedia:
http://en.wikipedia.org/wiki/Runge-Kutta
Note that the variable "h" that they use should be, in your case, the time step size. If the wikipedia entry is confusing, just do a google search for "Runge-Kutta" (named after some mathematicians) and you should be able to find plenty of stuff.

Edit: you can get info on the slightly less complex second-order version here:
http://www.physics.orst.edu/~rubin/nacphy/ComPhys/DIFFEQ/mydif2/node5.html
So it's a question of how sophisticated you want to get. You could even play around with comparing the different methods, and how errors scale with step size, etc.

Ziggurat
11th March 2006, 03:59 PM
Ah yes, the old problem of simulating gravity in discrete steps.

The only real solution is to use calculus and differential equations, which is what astronomers do for all but the basest of simulations.

That's not correct. Their simulations all have to use discreet time steps because you can't get exact solutions for many-body problems. The difference isn't the discreteness of the time steps (they all involve numerically integrating the differential equations of motion, including what Alkatran is doing), it's the sophistication of the integration techniques (such as Runge-Kutta mentioned above). The better techniques are indeed derived from calculus, but so is the crude Euler's method being used by Alkatran already.

Ziggurat
11th March 2006, 04:09 PM
Follow-up on Runge-Kutta:
The pages I listed show the algorithm for a single variable problem. But you're not really looking at a single-variable problem. It's actually not complicated to generalize the Runge-Kutta methods to multi-variable problems, and you could probably figure out on your own if you spent some time on it. But to save you the trouble, here's an example for how to do it with a two-variable problem:
http://www.nsc.liu.se/~boein/f77to90/rk.html
Once you see how to go from one variable to two variables, it should be obvious how to generalize that to any number of variables.

drfrank
11th March 2006, 05:11 PM
Calculus solution? Doesn't that only work for two bodies?

If I ignore all the other planets the effect is negligable, but I assume that the discrepancy grows larger as time goes by.

Right now it looks great. I put code in to calculate the time-step based on the 'simulation time to real time' ratio you want. It speeds up the simulation when it's overshooting and slows it down otherwise.
Unless you need high accuracy (in which case I suggest the JPL Ephemerides), assuming the planets are massless and only considering the effect of the Sun will do just fine.

An easy way to test the integration (for which I'd recommend variable step 4th order Runge-Kutta) is to integrate for several periods and see whether the body stays in a stable ellipse. Anything else (given that your initial velocity isn't great enough to cause a hyperbolic escape) and it's not good enough.

Euler integration will see the planet doing spirograph-type patterns around the Sun, even at small a time-step.

If you have any trouble getting this project to work then you can pm me, as this is a problem I've personally worked on during a research project a while back. I also have a polynomial ephemeris knocking around (with polynomials approximating the proper perturbations of the standard Keplerian elements), which is a couple of steps up in terms of accuracy.

Angus McPresley
11th March 2006, 08:38 PM
That's not correct. Their simulations all have to use discreet time steps because you can't get exact solutions for many-body problems. The difference isn't the discreteness of the time steps (they all involve numerically integrating the differential equations of motion, including what Alkatran is doing), it's the sophistication of the integration techniques (such as Runge-Kutta mentioned above). The better techniques are indeed derived from calculus, but so is the crude Euler's method being used by Alkatran already.

Well, I stand corrected. Perhaps I should add a disclaimer to my sig:

Warning: The above poster is probably talking out of his *ss.

:rolleyes: Thanks for setting me straight.

Alkatran
11th March 2006, 10:20 PM
The main problem I'm having is figuring out how this applies specifically to planets moving. It took me a good ten minutes to realize that x' was a derivative (made A LOT more sense after that, haha).

My question is mainly: what do I need the position value for when calculating the derivative with respect to time? Should my f(x, t) be

\$\$ f(t) = v + t*a \$\$

where t is the time difference between \$\$t_0\$\$ and \$\$ t_h\$\$?

Is the formula essentially just using the weighted average of 4 slope values then moving based on that average?

If both of those are true then the whole thing simplifies to

\$\$ x_{n+1} = x_n + t/3*(2*v + a*t) \$\$

which is my original equation with 1/3 less t*v and 1/6 less a*t^2

Alkatran
12th March 2006, 10:07 AM
Here's what it looks like now. I took it off Runge-Kutta because I'm sure I implemented it wrong.

The simulation runs at approximately 30 simulated days per real second and adjusts the time step as it goes. diameters are exaggerated by a factor of 10 and eveything is always at least 3 pixels wide.

http://myweb.dal.ca/cr376499/

The interface is a bit sloppy. Click on a planet to fix it and view all thingsrelative to it (including accel). Click and drag to look around. Left-click zooms in, right-clicks zooms out. I know that it can be hard to click on planets with them moving.

I like to click on Earth and see what it's like to be a geocentrist, haha.

JayT
14th March 2006, 08:19 PM
Here's what it looks like now. I took it off Runge-Kutta because I'm sure I implemented it wrong.

The simulation runs at approximately 30 simulated days per real second and adjusts the time step as it goes. diameters are exaggerated by a factor of 10 and eveything is always at least 3 pixels wide.

http://myweb.dal.ca/cr376499/

Your program seems to be shaping up rather well.

:o

Alkatran
14th March 2006, 08:27 PM
Thank you.

We're covering runge-kutta in class tomorrow so I can finally implement that.

drfrank
15th March 2006, 06:53 AM
Here's what it looks like now. I took it off Runge-Kutta because I'm sure I implemented it wrong.

The simulation runs at approximately 30 simulated days per real second and adjusts the time step as it goes. diameters are exaggerated by a factor of 10 and eveything is always at least 3 pixels wide.

http://myweb.dal.ca/cr376499/

The interface is a bit sloppy. Click on a planet to fix it and view all thingsrelative to it (including accel). Click and drag to look around. Left-click zooms in, right-clicks zooms out. I know that it can be hard to click on planets with them moving.

I like to click on Earth and see what it's like to be a geocentrist, haha.

Alkatran
15th March 2006, 07:30 AM
You need JRE 5.0 to run it. You can get it from sun.com if you enjoy walking through a maze for half an hour.

JayT
15th March 2006, 11:28 AM

That could possibly be because your browser security settings or firewall is blocking Java applications or you may not have the Java runtime (JRE) environment installed that is needed to run Java programs.

:)

drfrank
15th March 2006, 12:02 PM
That could possibly be because your browser security settings or firewall is blocking Java applications or you may not have the Java runtime (JRE) environment installed that is needed to run Java programs.

:)
Hey, are you accusing me of PEBKAC? :p

Alkatran's right - I almost certainly don't have the most updated JRE, although it's recent enough to run most JAVA stuff on the net. I'll look into it.

JayT
15th March 2006, 01:40 PM
Hey, are you accusing me of PEBKAC? :p

Alkatran's right - I almost certainly don't have the most updated JRE, although it's recent enough to run most JAVA stuff on the net. I'll look into it.

What does PEBKAC mean ?

Is that some form of dirty word ?

LOL

If he compiled his program with Java v5, you'll probably need the same version to run it. Not too sure about that though.

Hellbound
15th March 2006, 01:45 PM
PEBKAC:

Problem Exists Between Keyboard And Chair.

Also related:
ID ten T Error (ID ten T=ID10T)
UNSE Error (User not Smarter than Equipment)

I'm sure there are others :)

JayT
15th March 2006, 08:07 PM
PEBKAC:

Problem Exists Between Keyboard And Chair.

I do a lot of programming, so I encounter PEBKAC almost daily.

PEBKAC = my middle initials.

LOL

Alkatran
20th March 2006, 02:19 PM
Well the program is done. The moon leaves earth after awhile if you set the time step too high, but that's to be expected considering how small a period it has.

myweb.dal.ca/cr376499/

The large picture is just for the presentation in class...