Why Do Different Planetary Simulation Softwares Show Discrepancies?

[DaveC426913]

I am disappointed and a little alarmed to find big discrepancies between simulator software.


Following advice from https://www.physicsforums.com/showthread.php?t=84458", I tried simulating the same date: May 5 1975 with three simulators:


http://www.fourmilab.ch/cgi-bin/uncgi/Solar" (Online)
http://www.pwr-tools.com/simsolar/" (Download s/w)
http://www.orbitsimulator.com/gravity/articles/what.html" (Download s/w)

I got some non-trivial discrepancies between all three, and one has Mercury WAY off. I double-checked the results.

See attached file to show discrepancies. (I've rotated, zoomed and calibrated the charts for clarity.)

What gives?

 

[tony873004]

I'd say the winner is SimSolar!

But since I wrote Gravity Simulator, I can try to help you.

Gravity Simulator is not like the other two programs. They are better prepared to allow you to enter a date and instantly create the solar system based on that date. I'm surprised that their answers differ at all. I would have suspected that like most planetarium programs, they use a version of VSOP 87 for their analytical planetary positional computations.

Gravity Simulator is a numeric integration simulator also known as an n-body simulator. Although far from your best choice for a planetarium-type program, it allows you to do things that programs using analytic methods can not do. Most of the simulations on the "Simulations" link in my website exploit this strength.

To see planets in their accurate positions in Gravity Simulator, you either need to acquire accurate velocity and position vectors for each planet for the date in question, or start with a simulation designed to simulate the solar system (such as fullsystem.gsim), and then propogate the orbit backwards in time to your desired date. Extremely accurate starting data is available through JPL Horizons (if they don't get it right, our space missions fail :) ). There's instructions in the help menu on how to query for data for a particular date. I can help you if you wish.

Or you can begin with the simulation called fullsystem.gsim which is included in the Gravity Simulator install package. Just delete the objects that don't interest you, but don't delete the Sun, any planets, Earth's Moon, or Pluto's moon, Charon. This simulation (before you delete what doesn't interest you) contains nearly 200 solar system objects (all planets, all but the most recently discovered {<1 year} moons, some notable asteroids and comets, and some spacecraft .) The simulation begins on January 1, 2005. Every object has accurate position and velocity vectors supplied by JPL for that instant. Then, as you propogate the orbits forwards or backwards in time, errors start to grow. But they should still be small enough that 30 years +/- gives you accurate Mercury data.

Just to test your screenshot, I ran Gravity Simulator backwards from 2005 to 1975 using a time step of 16 seconds. It took about an hour. And then I made a new simulation with fresh JPL Horizons data for May 5, 1975 00:00:00. In my opinion, you can consider the screen shot generated from this simulation as your answer key. It's JPL's data, unpropogated. If they get it wrong, the Mercury Messenger spacecraft , with its Venus, Earth and Mercury flybys on its way to Mercury, is in big trouble.

I found the results of my 2 simulations to be extremely similar to each other, and most-resembling SimSolar's version of the Solar System, but not resembling your Gravity Simulator screen shot, at least for Mercury. Here's my screen shots:

http://orbitsimulator.com/BA/gsim0575.GIF
http://orbitsimulator.com/BA/gsim75.GIF

Which Gravity Simulator simulation was your starting simulation, and what time step did you use? It's tempting to use too large of a time step, because who wants to sit around for an hour while the computer chugs through every inch (or more accurately hundreds to low thousands of kilometer chunks) of each planets' orbit 30 years back in time? But if your time step is too large, Mercury is the first planet to show it. Try pumping the time step up to a few days, and watch Mercury get needlessly ejected from the solar system, Venus and Earth cross orbits, and Jupiter and beyond happily orbit like nothing happened.

Gravity Simulator is a continuous work in progress. The latest version, not yet released, is slightly more accurate. JPL was kind enough to provide me with values they use for the Gravitational Constant, and for solar, planetary, and moon masses. These values have more digits than I have found elsewhere.

The version you have begins to lose accuracy on the positioning of Earth's Moon after a few years, but with the new numbers, the Moon only misses its alignment for the August 2045 solar eclipse by a couple of moon diameters. Amazing what tweaking the numbers 10 places to the right of the decimal point will do!

 

[neurocomp2003]

is this in C/Fortran?

 

[tony873004]

I can't speak for the other 2 programs, but Gravity Simulator is in C++ / Visual Basic.

VB is simple to use but slow. So for the parts of the program that don't require speed, I use VB.

C++ is fast. The engine is in C++. This resulted in a 10x improvement in speed. You can test the difference by temporarily renaming (so the program can't find it) the file codeoptomizer.dll in the folder that contains gravitysimulator.zip. This dll contains the C++ portion of the program. It resorts to an identical VB procedure if it fails to find this file.

 

[DaveC426913]

Indeed, I was playing with the time increments. I sped it up to 65535 for a while.

 

[tony873004]

At 65535, you'll notice that Mercury seems to orbit just fine. That's about the fastest speed you can do before it changes the shape of Mercury's orbit. However, even at 65535, Mercury's orbit has an unnatural precession to it. 16 was probably needlessly slow. But it worked well for me since I had to go out for an hour anyway. I didn't want to return to some date in the 1800s.

Even running the simulation at 65535 for a short time, and then returning to a slower time step will ruin the accuracy.

 

[neurocomp2003]

do you use some template coding in these sims

 

[tony873004]

I'm not sure I understand your question. Each sim is not a separate program. It's the same program with different starting conditions.

 

[DaveC426913]

At 65535, you'll notice that Mercury seems to orbit just fine. That's about the fastest speed you can do before it changes the shape of Mercury's orbit. However, even at 65535, Mercury's orbit has an unnatural precession to it. 16 was probably needlessly slow. But it worked well for me since I had to go out for an hour anyway. I didn't want to return to some date in the 1800s.

Even running the simulation at 65535 for a short time, and then returning to a slower time step will ruin the accuracy.

This confuses me - it appears to contradict itself. Is 65535 going to give accurate results or not?

 

[neurocomp2003]

oh i meant in the actual code for the program...do you use template coding?
I'm trying to figure out what types of coding concepts one should not use when dealing with high performance/large sims.

I wasn't talking about the parameter fiddling for the sims themselves.

 

[tony873004]

This confuses me - it appears to contradict itself. Is 65535 going to give accurate results or not?

It depends on what results you're after. If you want to demonstrate that a planet orbiting a solar mass star at Mercury's SMA will orbit the star with a certain approximate period, 65535 would be fine. It would also demonstrate that Mercury's orbit is stable over the course of the simulation, in that it doesn't drift into a Venus-crossing orbit, or crash into the Sun.

But errors from too large of a time step will first show up as positioning errors. ie. Mercury's orbit will retain its proper shape and orientation, but exactly where it is in its orbit is no longer accurate. Increasing the time step further will introduce unnatural precession into the orbit. This unnatural precession is present in slower time steps, but it is not significant. Mercury's orbit naturally precesses due to pertabutions from the other planets, and to a much lesser extent to GR (not modeled by Gravity Simulator). But at 65535, error from the time step also introduces a precession that is not natural to Mercury's orbit. Planets further will need a larger time step to have significant precession error.

So for showing somebody a scale model of the solar system where the planets retain their correct spacing and eccentricities, 65535 is fine. But to determine where Mercury will be in 30 years from now, 65535 is too fast.

Another example. Consider the simulation on the website called Saros Cycle. Just for visual effect, this simulation is run fast at 16384. The Moon continues to orbit the Earth, at the correct distance, with the correct eccentricity, and the correct inclination. The nodes even precess in their 18 year cycle, which is the goal of this simulation. So based on this simulation's goal, to demonstrate the Saros cycle, 16384 is a good time step. It would be boring to watch this simulation at slower time steps. Any time step larger would significantly distort the shape of the Moon's orbit.

But if you pause the simulation and compare the Moon's position in its orbit to its expected position, it will not match (or if it did, it would be coincidence). You might find the Moon at its 1st quarter position rather than at full moon where you expected it, etc.

To summarize, as you increase the time step, the errors will grow from insignificant to significant in this order:

1. Position accuracy degrades
2. Orientation of the orbit degrades due to unnatural precession.
3. The orbit's size and shape are altered.
4. The object gets ejected at an unrealisticlly high speed from the system.

 

[tony873004]

do you use template coding?

Since I don't know what template coding is, I probably didn't use it.

 

[neurocomp2003]

perhaps I'm using teh wrong term...my apologies if i did. This is the type of code I was asking about.

template<class TempClass>
class ClassName {
};

 

[tony873004]

It's ok. I'm not a professional programmer, so you might be using the proper term even though I've not heard of it.

There's nothing in my code that resembles what you've typed.

 

[franznietzsche]

perhaps I'm using teh wrong term...my apologies if i did. This is the type of code I was asking about.

template<class TempClass>
class ClassName {
};

In general physics simulations are very simple from a computer science perspective.

 

[tony873004]

In general physics simulations are very simple from a computer science perspective.

To elaborate, my program is a few thousand lines of code. But most of it is user interfaces, etc.

The actual engine, the part that does the physics, is about 30 lines of code.

 

[franznietzsche]

To elaborate, my program is a few thousand lines of code. But most of it is user interfaces, etc.

The actual engine, the part that does the physics, is about 30 lines of code.

Exactly. The simulation is very simple from a computer science standpoint. Interfaces are not the simulation.

The most complicated simulation code I've ever worked with was about 18,000 lines in total, a solar evolution code. It was monstrous. My own codes are only a few hundred lines usually, and rarely have anything more complicated than subroutines and functions (I generally use Fortran, I have never needed anything that C had that fortran didnt. The most complicated bit of code I've used I think was calling other functions as arguments to a subroutine. Well, excluding Perl code anyway, but that's not simulation code.)

As a side note, I'd be interested in seeing your interface code, as that is an area I have very little experience in. Assuming you're willing, of course.

 

[neurocomp2003]

ah coo,
yeah i understand the physics equations would be very small in code unless you use lots of numerical packages.

but do you uise any special scene managment techniques? Octree/quadtree/kdtree?

What do you use for the visualization or camera? opengl or vb?

 

[tony873004]

Interface code will look a little strange if you've never used an object-oriented "visual" style programming.

The visualization is VB. I've considered switching it to opengl or directx, but I don't know much about either, and I have hundreds of things on my to-do list above learning them. Using them would open up a whole new window of opportunities for me. But making use of such opportunities would only make my program more Orbiter-like, or more Celestia-like, with eye-catching graphics. But for the types of things I like to do with Gravity Simulator, simple pixel graphics are just fine. I just use Orbiter or Celestia when I get a craving for planets that actually rotate and look like planets.

 

[neurocomp2003]

coo, thanks for the reply