scott wrote:

> It's easier to understand if you consider a single function to integrate 
> first, rather than doing acceleration/velocity and velocity/position in 
> one go.

Er, yes.

OTOH, almost all physical systems are of this type.

(Unfortunately, all the texts explaining this stuff use abstract 
mathematical functions, which makes it extremely difficult to figure out 
what's going on.)

> There is a clever trick that lets you do both of these together 
> without much extra work, but it's not too obvious and usually confuses 
> things.

I'll bet...

> As you are aware, the problem is that with large time-steps big errors 
> appear because you are assuming the average velocity during the time 
> step is equal to the instantaneous velocity at the beginning of the time 
> step - this is only approximately correct!
> 
> All RK4 does is to find a much better estimate of the average_velocity 
> during the time step, then you can use that to advance x with much 
> higher accuracy.

So it gets a more accurate average velocity by sampling it more?

> Now we have four estimates for the velocity, one at the beginning of the 
> time step (standard Euler), two in the middle, and one at the end of the 
> time step.

Right. I don't really understand why it has to be these exact points...

> The RK4 algorithm then tells us to take a weighted average of these 
> velocities:

...or why this specific weighting is the correct one. But hey, I guess 
somebody had a reason for that.

> That is it!  That is the estimate of average velocity over the entire 
> time step.  You will have noticed we called F four times, but doing this 
> is MORE accurate than simply doing four dt/4 Euler time steps.

Clearly I'm going to have to meditate on exactly why that's the case. I 
would have thought that taking 4 seperate steps would be more accurate 
than computing 4 steps and then blurring them all into one step, but hey.

> You should be able to simply compare the values of AVE1,AVE2,AVE3,AVE4 
> to determine if you need to go back and do a smaller time step.

Mmm, OK. I'll take a look at some numerical work and see what happens...

> Now to make things more general, you can replace the position "x" by the 
> generic "state" of the system, and the velocities by the "derivative of 
> state" of the system.  This way, the functions F and RK4_Algorithm will 
> return objects of type "derivative of state".
> 
> If you are dealing with forces acting on particles, then the "state" of 
> each particle is its position and momentum (4 variables in 2D), and the 
> "derivative of state" is its velocity and force (another 4 variables).
> 
> Now, your function F must return the velocity and force.  The force it 
> calculates based on your magnet formula or whatever, and the velocity it 
> can easily calculate by dividing the supplied momentum value by the 
> mass.  That last part is the key that links the two differential 
> equations together, and why it is sometimes complicated how RK4 can do 
> both at the same time for acceleration and velocity.

Hmm... How is momentum and velocity different?

Oh, wait - the mass could be non-unital. I forgot about that...



Thinking about Euler integration, you end up doing something like

   x' = x' + dt x''
   x  = x  + dt x'

In other words, you compute the new velocity from the old one, and then 
assume that velocity is constant while you compute the new position from 
the old one. But if you assume that acceleration is constant, you can 
actually *exactly solve* for position. I can't figure out the equation 
off the top of my head, but it would be some kind of quadratic curve. I 
wonder - would this give you any more of an accurate result?

Post a reply to this message