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.

Well I'm stumped. Here's a 60 year animation of the belt, but this time the asteroids have 0 mass and 0 radius, so they're massless points. And still the flicking is there (and it looks pretty much the same as the previous graph, so I doubt if it's anything to do with the asteroids perturbing eachother). To give an idea of scale, the eccentricity is varying between the order of 1e-5 and 1e-3 here.

Given that it's still happening with massless points (so they can have no gravitational influence at all on eachother), could this just be down to some kind of rounding/calculation error in the program? I can't think of anything else it could be, since gravity can't be the cause.

Though strangely enough, if you look at the animation, the flicking seems to go from left to right from the inner edge of the belt, but from right to left from the middle/far edge of the belt, and it seems to converge on 1 AU. Is that real or just an illusion of the animation? Could that signify anything?

In my opnion this is due to the algoritm of integration of the Euler method . This method works very well , but induces some inaccurancies of the positions of the asteroids . The closer the objects come , ie as speed increases the error increases also . In the long term the effect is almost zero , but individual values tend to oscillate around the exact value . If you run the same at smaller timesteps the error should decrease also . I wonder how Tony interpretes this .

To try out Frank's idea, I ran the massless particle simulation again but at a 4k timestep. Sure enough, the oscillation is smaller (as shown below - the vertical axis is the same scale as before), so I think he's on to something. Again the scale of the oscillation is small, of the order 1e-3 to 1e-5.

If it is indeed a calculation issue, is there any way to reduce this at higher timesteps (sure, we can run the sims at lower timesteps, but then we'd never get anything done because it'd take forever to run them!)? Could this issue be introducing errors that are propagating into all the bodies in all the simulations? (e.g. if a given asteroid's eccentricity would only be pumped to higher values by another body if it was greater than zero, then these errors could be causing the orbits of bodies to evolve that shouldn't be evolving)

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.

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.

I'm doing a new run with 250 massless point asteroids located between 0.01 AU and 1.99 AU. Obviously at 4k the innermost asteroids are going to be a bit weird because the timestep is too high for their orbits, but I do expect the fluctuations to increase as you get closer to the star. (and I've got the latest beta, and the the system energy is 0x10^0 joules, because everything is massless).

Are all the variables set to the highest possible precision in the program? It seems odd to me that you're getting this kind of fluctuation - if it was just rounding errors then wouldn't the error be much smaller?

The problem I see here is that for the innermost orbits of any simulation, you've got a double-whammy of these fluctuations caused by the calculation errors, *and* errors caused by timesteps being high enough to run the sim in a timely manner (I'm sure it'd be great to run every sim at a 16-second timestep, but we want them to finish before the year 2100!).

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. .

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 .

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 .

That's what I did in the other thread, but it didn't look like the fluctuations were higher with the jovian there. Yes, there were bumps and peaks caused by resonances, but the general background fluctuation looked to be the same.

EDIT: I just checked the text files and asteroid 20 (located at the inner edge of the belt) fluctuates the same way and to the same extent for both runs - between 0 and 0.006 (see below). Well, actually the frequency of the variations is very slightly different, but the shape of the graph is the same whether the jovian is there or not.

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 ...

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 ...

Yeah, except if you run the sim at low timesteps for those bodies, then any more distant bodies are going to be dead slow!

Hm... Tony, would there be any way to have a variable timestep within a simulation? Like, if the sim contains bodies close to the star then their timestep is automatically reduced to less than the outer bodies? Though I guess you'd need a way to synchronise the output otherwise less time will pass for the inner bodies than the outer ones... so maybe not.

It seems odd to me that you're getting this kind of fluctuation - if it was just rounding errors then wouldn't the error be much smaller?

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:

Tony, would there be any way to have a variable timestep within a simulation?

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

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.

Hang on though - isn't Mercury's precession due to relativistic effects too? Unless gravsim accounts for that then it should never give an truly accurate simulation of that - it should just give a result consistent with what you'd expect from Newtonian physics shouldn't it?