To explain how computational flutter works, we first have to explain the basics of how X-Plane manages the flight model. Unlike the real world where physical effects are smooth, continuous functions in time, X-Plane computes the flight model in discrete steps. That is, it does all the math necessary to work out what the plane is doing at some instant in time, adjusts its position and velocity accordingly, and then continues to do it over and over. Each set of computations takes a certain length of time. The interval between each set of computations determines the frame rate.
The way you do a simulation of motion in discreet steps goes as follows:
Now... how does this cause computational flutter?
Many real world processes are "self-correcting". That is, motion in response to a force creates an opposite force that damps out the motion. Three examples:
But the real world doesn't work in discrete steps. In the real world an infinitesimal change in motion or position instantly causes a change in force. In the discrete model, as long as the changes in force, velocity, and position are relatively small from step to step, all is well and the results are pretty close to the real world.
Where you get in trouble is when you get a large enough change from one frame to the next so that the net force is reversed. Think about stepping on a spring. The force of your weight accelerates you and the spring downwards. The longer the integration time (frame to frame time interval), the longer your full weight is applied to the spring, and the further the spring is compressed before the simulation model "notices" that the spring is now compressed. Take this far enough, and in step n+1 the spring is already compressed so far that the opposing force exceeds double your weight. The net force now exceeds your weight, upwards! What happens? You are accelerated upwards, at a higher rate than you came down in the previous step. Look ahead to step n+2: You end up bounced higher in the air than you started at step n; in step n+3 you end up lower with even more spring compression, go even higher in step n+4, etc. The result is divergent oscillation.
"But, but, but... That's not what I see in the plane's behavior, " you say. "What I see is a sudden, increasing roll in one direction, or unexplained acceleration." (Hmmm... remember the Audi 5000?) When I graph the flight parameters or log them to a disk file, all I see is a steadily increasing force on one direction. What's going on?
Two important facts come into play:
What to do?
X-Plane 7.41 claims to have some measures to detect and control computational flutter. Time will tell how well they work. You can prevent it by staying inside the flight model "envelope", i.e., by running X-Plane in such a way so that nothing changes too much from frame to frame.