I don't have a specific answer, only a thought, or possible approach. Your problem made me think of astrodynamics work I've done (computation of the orbits of satellites, spacecraft, debris, asteroids, etc). That field has a similar problem. If you try to compute orbits the "obvious way", namely just sum the gravitational forces of relevant objects (usually sun and planets), to get any sort of precision you must reduce the time step to absurdly tiny increments, and the computations take forever (far longer than is practical).

In effect, at each time step you compute the position and velocity, compute the next position, then repeat. Which means, the computation assumes the object moves in a straight line between computations. While that may seem reasonable given the huge distances involved, the difference between the computed and actual path is fatal to medium and long term precision.

The usual solution is to go ahead and compute the forces of massive objects at each timestep, and adjust the direction and velocity accordingly. But then what you do is take that linear position and velocity, and compute the conic (ellipse, parabola, hyperbola) orbit that position and velocity corresponds with relative to each massive body (sun, planet, moon), and sum the changes in position and velocity those influences generate (to the conic orbits). Therefore, the changes between time steps are not linear, but correspond to conic orbital paths, which are correct to vastly greater precision.

This is, of course, annoying, since at every step we must convert from linear position, velocity, acceleration to [multiple] conic orbits, then perform computations, then convert back to linear again. However, that's what it takes to assure the spacecraft or asteroid passes near earth (or moon, etc) rather than impacts into it, or vice versa, or gets lost over time, etc.

You likely need to find something similar... some way to represent and compute motion through fluids over longer time frames, then convert back to linear form again at each conveniently long time step. I don't know what those longer-term path equations are, but you probably need to find out. This approach will help (if you can find the appropriate equations), but your "longer time step" still can't be too long. I'm guessing maybe 0.100 to 1.000 seconds may be practical.

That's my best guess off the top of my head.

**Edited by maxgpgpu, 14 February 2013 - 04:42 PM.**