I am a student in Astrophysics (Bologna University, Italy)  and i want to know how accurate is Gravity Simulator.
 
In detail, i want to know what is the numerical method (hermite, runge kutta 4th, sympletic....) used by that program    .
 
It's important because i'm writing my thesis and i must write a N-body code, that resolve, for example, this kind of problem:
 
http://www.princeton.edu/~rvdb/JAVA/astro/galaxy/DustDisk.html
 
http://astro.u-strasbg.fr/~koppen/body/SaturnRing.html
 
Someone know if there is yet a routine to do this in gravity simulator ?
 
Thanks everybody.

RK4 generally works better than Euler; it takes about 4 times as much calculation per step, but increases accuracy by a much larger factor, so you can use larger timesteps without losing accuracy (that's why it's the default in my own program ). Euler is better when you need a simpler method, or if you want to do a quicker "test run" of a simulation.
 
Euler's method can actually be a bit misleading, as high timesteps can ruin accuracy but won't necessarily break orbits; they'll just become elliptical and precess rapidly instead. You can see this in galilean.gsim, for example, if you set the timestep to 2048+ seconds; the moons stay in orbit, but their orbits change in unrealistic ways, and they become stable again if you reduce the timestep. This isn't necessarily a bad thing, but if you want very good accuracy, it's something to watch out for.

AFAIR one important feature of the Euler method is that it conserves time reversal results , which may be unique vs other routines such as RK.  
What I mean is , if you run 1000 hours forward and then 1000 hours backwards you should end up at the same position using Euler .  
This isn't the case with other routines.

First, download this file into your Gravity Simulator folder.  Then use it instead of gravitysimulator.exe
http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2011May30.exe  
 
This is the beta version that lets you choose between Euler-Cromer and Runge Kutta 4.  In the beta menu just choose which integrator you want.
 
If you want to edit it, you can either:  1) send me your changes and I'll do it for you, or 2) do it in C++, compile it into a dll named codepotomizer.dll, then replace the existing codeoptomizer.dll in your gravitysimulator folder, then finally, download the most recent beta version not counting 2011May30.  Then it will use your C++ code instead.
 
To output data:  
First, create a simulation and save it.  It is recommended that you save it in its own folder.
 
File > Output File (don't choose systemic).  Check the "Create Data File" box and the "Create Data File Copy" boxes.  It then creates 2 files.  The difference is that you can play around with the copy while the simulation is running.  For example, if you open the data file in Excel, then Gravity Simulator can not write to the file.  The original copy cares about this, while the copy does not.  The copy won't update again until you close it in Excel, then it will copy the original version so they're identical again.  Then choose how often you want the data to be written to the files, and the maximum number of data samples.  Then choose for which objects, and finally choose what orbital elements you want written to the data file.
 
The files are created in the same folder as your .gsim simulation file.  They have the same name as your .gsim file, except the extension is .txt.  In Excel, choose file type txt and browse to the file.  Choose deliminated, and choose the comma as your delimiter.  Then it should open for you.  If you want .xls, you can save it in Excel with file type xls.
 
Here are step-by-step instructions for creating the first simulation you linked to:
 
Open Gravity Simulator and pause the simulation
Open "fullsystem.gsim" which is in your "simulations" folder.
Objects > Delete
Delete all unwanted objects.  Your article talks about the "14 main bodies".  From their list I would delete Haley's comet as one of the 14 main bodies.  You might also want to exclude  Sedna, Eris and Pluto.  If not, you might as well keep Ceres, Pallas, Vesta, and Juno, as they're more significant as Sedna.
 
Save your simulation.  Create a new folder for it and give it a name.
 
The link you provide uses 2000 massless test particles.  I'd suggest starting out with 200 until you are comfortable with creating simulations.  Besides, 200 should be fine to show you their general distribution after a given time since they are massless and don't interact with each other.  It says they are in circular orbits with inclinations distributed between 0 and 5 degrees.  The article doesn't mention how they're distributed in distance. But looking at their animation, there don't seem to be any interior to Earth's orbit, and they seem to stretch out to Neptune.  So let's just assume that they're evenly distributed between 1 and 30 AU.
 
Objects > Create Objects
Number of objects: 200
Semi-major axis:  First hit the distribution button until the words "Start, End" appear under SMA.  Make sure that AU is selected as your unit of distance.  Enter 1,30
Inclination:  Choose 2.5 degrees +/- 100%
Make sure the reference object is the Sun.
Give them a name such as "Asteroids"
Press Create
Under menu > Preferences, set the "Do Events" to 5 so your program doesn't seem non-responsive due the high number of objects.  Also set the Graphics Updates to 50 to speed things up.
Save the simulation.  Give it a different name than before in case you need to start over.
Unpause and watch.
 
To hold Jupiter still like they have in your article, use menu View > Rotating Frame Adjustment.  Choose Jupiter.  This gives you approximately the right period for the rotating frame.  Experiment to come up with a better value.  Hit "Calibrate" and click on Jupiter.  Return a few minutes later and click on Jupiter again.  Gravity Simulator will then compensate for Jupiter's drift.
 
To make the asteroids appear different colors depending on whether they're above or below the ecliptic, menu Objects > Edit Objects.  Select each asteroid and put an asterick after its name and hit "Apply".  I don't have an automated way to do this, sorry, so you'll just have to spend a few minutes and do them one at a time.  Any object with * as the last character of its name appears red when below the ecliptic.
 
One more change I would make is to use Earth Barycenter rather than the Earth and the Moon.  With the Moon orbiting the Earth, this sets the maximum step size you can use, preventing you from taking huge time steps like the 3 days they use in your link.  Even so, I'd keep the time step to 16K seconds or less.
 
Following my above instructions, I just made one for you.  You can get it here:
http://orbitsimulator.com/gravity/simulations/frederico.gsim
 
At a timestep of 16384, it does about 6 years per minute, or about 27 hours to do 10000 years, so you'll want to run this thing over night, save it, and run it again the next night or any time your computer is free.  You can speed things up a bit by pressing the P button on the Graphics Options interface.  This disables the graphing.
 
 

Quote from guyy on 05/30/11 at 20:56:51:

It definitely seems to work.  RK4 allows an object in a circular low Earth orbit to orbit for months (maybe longer) without deviating from a perfectly-circular orbit by even 1 meter at time steps as high as 16 seconds.  At a time step of 1 second, EC deviates by about 300 meters high or low from a perfectly circular orbit.  However, it can maintain this indefinitely without the error growing.  So this gives me confidence that I coded the RK4 properly.
 
But during longer simulations with larger time steps, EC seems to be the winner.  I downloaded JPL elements for the solar system from yesterday's date, including the asteroid Apophis.  Using EC, I propagated the system forward until April 13, 2029, the date that Apophis will pass within 30,000 km of Earth.  Then I compared my results with JPL's predictions.  EC's Apophis was 10,000 km away from JPL's predection with a time step of 128 seconds.  As I recall from trying this previously, with time steps as low as 1 second, EC is only about 200km from JPL's prediction.  When I tried this in RK, I needed to increase the time step to 1024 seconds so RK, with its longer code, would complete the mission in the same amount of real time.  When Apophis arrived, it was over 1 million km from JPL's predicted position, and Earth's moon had its eccentricity pumped up to over 0.2.  I'm in the process of doing a much slower RK run at a time step of 16 seconds, but it will take 27 hours to complete.  Perhaps by tommorow night I'll have an answer.  But unless I made a mistake coding, it seems that EC is more robust for solar system simulations.  Soon I'll write up a summary of all my testing.
 
Quote:

I think it depends on the size of the system.  In a 2-body system containing the center of the galaxy and the sun, much larger time steps can be taken than with the Moon orbiting the Earth.  I think it has more to do with how many steps it takes to complete a full orbit.

thank to everybody !!!!  
 
I "created" my simulation and I observed some very interesting results:
 
1) the scattering theory (or slingshot effect) is confirmed by simulation: the internal objects give energy to the outer spiraling toward the center of the system while the outermost buy energy and spiraling out, this is the phenomenon of in-outward migration.  
 
http://astro.u-strasbg.fr/~/body/SaturnRing.html
 
2) I also noted the phenomenon of precession of the outer objects which I do not expect it at all.  
This is very interesting and deserves some explanation.
 
3) I would add the number of collisions of objects because I think that, you can solve the inconvenienceof the explosion of the inner system.
 
I give by email my result (because i can't link it here   ) , open to any questions, improvement     or clarification.

Quote from guyy on 05/30/11 at 22:31:35:

You're right.  I had some plus signs where I should have had minus signs in the code.  I'm testing it now and it's passing the Apophis test with flying colors.  I'll release a new beta when I'm finished.  In the meantime, don't use my RK4!