(I split this from the "new system" thread)
 
STOP THE PRESSES!!!
 
I had a suspicion about this, so I tried it out - I removed ALL the planets and just left the belt to evolve on its own for 160 years, just to see what happened. As you can see from the animation below, even with no other bodies in the system (apart from the sun) the 'flicking' that propagates outward from the inner edge of the belt is still there!! Though obviously since there's no jovian anymore, the bumps at the resonances aren't there anymore.  
 
The only possible reason I can think of for this (unless this is some bug in Gravity Simulator itself or something to do with the timestep?) is that it's because the asteroids aren't massless - when I defined them I gave them a radius of 0.5 km and a mass of 100,000,000 kg (100,000 metric tons). So could they be perturbing eachother, and that's what's causing the flicking? I also wonder if the reason that the 'flicking' starts at the inner edge of the belt is because those asteroids are the ones that are orbiting the fastest - as the outer asteroids complete their orbits up the 'wave' propagates outward too? Though I still don't know what the flicking actually is.... Either way, I really can't think of any other cause for the flicking given that there's no other bodies here - I guess the only way to find out for sure would be to recreate the belt but make the asteroids massless points (can we do that in GravSim?) and see what happens...  
 
But at least now we seem to have proven that the 'flicking' is a natural property of the belt itself (or a bug in GravSim or a timestep issue ), not caused by jovians or any other bodies.
 
Anyone got any ideas about this???
 

Frank reckons this may be caused by the Euler algorithm itself:
 
Quote from frankuitaalst on 10/12/08 at 02:45:17:

Your methods for investigating this are correct.  Make them massless, and try different time steps.  Cutting your time step in half should drastically reduce the error.  Cutting it in half again will cut it even more.  You can also go the other direction.  Try a larger time step and see if the error grows.
 
If the effect is natural, you should see it asymptotically approach its true value as you keep lowering the time step.  It's similar to what was discussed in the last post this thread:
http://www.orbitsimulator.com/cgi-bin/yabb/YaBB.pl?num=1158230793/5#5
where Mercury's perihelion drift differs from the Newtonian value at high steps, and asymptotically approaches the true value as the time step is lowered.
 
All the orbital elements will have this effect.  This is one of the challenges of doing n-body models is determining if the error introduced by the numerical method is significant enough to render your results meaningless.  I imagine with Jupiter in the system, the variation in eccentricity is much greater than this "background level" of 0.001 to 0.00001.  It makes sense that the error is larger for the interior orbits, as they orbit the sun with fewer steps per orbit than the outer objects.
 
If you have the most recent beta version, there's a new feature in the view menu called "system energy".  Since energy is conserved, this should be a fixed value.  Any fluxuation must therefore come from the integration routine.  Notice that there is always fluxuation, as there must be unless we had an infinitely small time step and variables with infinite precision.  But as the time step is lowered, the fluxuations decrease.
 
In any simulation, the easiest way to see if numerical error is affecting your results is to repeat the experiment at a slower time step and see if you get the same result.  If you don't, then you're running too fast.

Quote from Tony on 10/12/08 at 11:01:52:

In order to investigate if the error are allowable you can run the system as it is first ( only asteroids ) and then add fi the Jupiter in a new simulation . Both simulations at the same timestep . You'll see the disturbancies in the second case are much larger .  
I can imagine your concern about the effect of this small perturbations but I think their influence is small in general .  
 

Ok, here's the run with 250 massless particles between 0.01 and 1.99 AU at 4k timestep for 50 years. Within about 0.2 AU the results are too chaotic because the timestep is too high for those orbits.
 

I think you just have found a method to define a good timestep  
If the results for 0.2AU are acceptable , you can calculate the orbital period of these bodies and relate them to the timestep used .  
This ratio can be used to define a good timestep in case of higher and slower orbits ...

Quote:

There are two types of error introduced:  Roundoff error and truncation error.  Roundoff error is caused by the precision of the variables.  Gravity Simulator uses double precision.  If variables had infinite precision, there would be no roundoff error.  Truncation error is introduced by the time step.  If your timestep were infinitely small, you would have no truncation error.  
 
For most of the stuff we do with Gravity Simulator, the errors are insignificant with a reasonably slow time step.  But sometimes that is not the case.  In the example of the precession of Mercury's perihelion, it was necessary to take a time step of 64 seconds to get it to precess properly.  So for demonstrating the long-term precession, a slow time step was necessary.  However, if you wanted to simulate the Messenger mission to Mercury, you could take much larger time steps, as that mission only lasts a few years, and Mercury's precession will drift very little, so Mercury should be within a few km of its true position
Quote:

I tried this once, but the bad outweight the good.  Someday I might try it again.

Quote from Mal on 10/12/08 at 14:32:20:

I mentioned that
Quote from Tony on 10/12/08 at 11:01:52:

 
It's somewhat irrelavant though, as the difference betweeen relativistic and Newtonian is small compared to the errors introduced with a high time step.