flat rotation curves and 'foam' large scale struct

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Larry Burford</i>
Does your method make any explicit assumptions about the speed of propagation of the force assocoated with these time dependent electric fields? In particular, do you use c, the speed of light, as the force propagation speed in these calculations?
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

For the case of the charged particle orbits I assumed both homogeneous magnetic and electric fields, so the issue of propagation speed did not arise.

For the calculations with the 1/r^2 potential, I did not consider the effect of a finite propagation speed of the force as a) these were only some test calculations I did more or less for fun and b) in my opinion any static force field must be instantaneous anyway (see my webpage regarding Retarded Forces )

Thomas

The algorithm I use is as simple as possible to serve as a platform for all kinds of experiments with gravity.
The calculations are made in the following order:

Do
Distance
(Speed)
(Timestep = Distance / Speed * Timestep_constant)
Acceleration
New velocity
New position
Loop

The only diference between fixed- and variable-timestep is the lines in brackets.

Note that Distance / Speed actually gives the right dimension of time. On very close encounters calculation time gets high, but the bodies are never catapulted away from eachother.

___

Taking propagation delay into account in a variable-timestep is asking for trouble.
However, I tried it in the fixed scheme a couple of years ago. As soon as I saw what happened (orbits spiraling outward) I stopped my experiments and found myself back into thinking mode.

___

The first time I programmed something like this was on a 48kb supercomputer known as the ZX-spectrum.

The behavior observed by Michiel (unstable orbits when force propagation speeds close to c are used in the calculation) is why I was asking Thomas about this.

Real forces like gravity must of course have a finite speed of propagation. But unless that speed is much larger than c it would result in real orbits being unstable (spiraling outward if the force is attractive like gravity). And spiraling inward for repulsive forces like photon pressure, which is actually observed for small dust particles orbiting stars. Their mass is small enough relative to their surface area that the force caused by photon presure causes significant acceleration of the dust particles.

===

Observations from massive binary stars presently set a minimum value for the propagation speed of gravitational force at about 2 X 10^10 times light speed. So far we have no way to estimate an upper limit, so it could be much higher.

Given that the minimum is so high and that we don't know what the maximum is, using infinity as an approximation works fine. Not including a factor that divides particle to particle distance by propagation speed is the same as using infinite propagation speed. Best practice would be to include an explicit term for propagation speed and assign it a value of 20 billion c or greater. This would produce a more realistic simulation but would also slow down the calculation. The difference between the two would pobably show up somewhere between the 6th and 12th decimal places.

===

Thomas - since you are assuming infinite propagation speed (no explicit term for it), it might worth your while to add an explicit term and see how your model's behavior changes with different values. A possible side benefit of doing this is that while doing it you might discover something else in your code that is causing your original energy leak.

By the way, when you

Do
Distance
Speed
Timestep = Distance / Speed * Timestep_constant
Acceleration
Half the new velocity
New position
Half the new velocity
Loop

stability increases with eccentricity.
Circular orbits have an energy leak which increases the size. I'm trying to get the best of both worlds.

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Michiel</i>
<br />The algorithm I use is as simple as possible to serve as a platform for all kinds of experiments with gravity.
The calculations are made in the following order:

Do
Distance
(Speed)
(Timestep = Distance / Speed * Timestep_constant)
Acceleration
New velocity
New position
Loop

The only diference between fixed- and variable-timestep is the lines in brackets.

Note that Distance / Speed actually gives the right dimension of time. On very close encounters calculation time gets high, but the bodies are never catapulted away from eachother.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

I am actually not sure if making the step-width proportional to Distance/Speed is the ideal solution here. The 1/Speed factor seems reasonable enough but you would expect the numerical error to depend also on the curvature of the orbits. Now the latter is given by the force and hence proportional to 1/r^2, so I would try if r^2/v rather than r/v gives a better choice for the timesteps, so you might want to try

Timestep= (r^2*v0/r0^2/v)* t0

where v0 and r0 is a reference speed and distance respectively, and t0 is a standard timestep which has to be adjusted according to your requirements.

This would mean even more timesteps for small distances, but fewer for larger distances, and the overall numerical error should be smaller for the same total number of time steps.
That's merely a suggestion though, I have never tried it myself.

Also, did you ever try to couple the integration with a Runge-Kutta method? This might be more efficient than just using a simple Riemann or trapezoidal rule.

Thomas

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Larry Burford</i>
Thomas - since you are assuming infinite propagation speed (no explicit term for it), it might worth your while to add an explicit term and see how your model's behavior changes with different values. A possible side benefit of doing this is that while doing it you might discover something else in your code that is causing your original energy leak.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
First of all, I don't see any point in adding effects that in my opinion are theoretically impossible (as explained on my page www.physicsmyths.org.uk/retard.htm for static forces in general).
Secondly, there is nothing else in my code causing the 'energy leak' apart from the finite time steps. If I make the time steps smaller, the energy leak becomes correspondingly smaller as well, i.e. for a zero time step it would be zero.