# Why are flight simulators bad at predicting drag and lift values at high angles of attack? (the nonlinear flow regime)

X-Plane is built on something called blade element theory. From my understanding, it says the aircraft performance can be found if the performance of 2D cross sections are calculated and integrated in real time. Laminar Research (the maker of X-Plane) uses that as a selling point for X-Plane, saying it can be used to help aircraft designers try out their designs in flight on the computer before building prototypes. However, as commentators on this forum have written before (Peter Kampf), most flight simulators are bad at predicting the performance of the airframe at high angles of attack without using a table of force coefficients generated through windtunnel data or detailed CFD.

My question is, what in the flow physics drives this? What part of the physics is modeled incorrectly to give garbage data at high angles of attack?

• The difference is in matching the outcome of the physics model with real measured flight data, which is indeed proprietary and very expensive. You can model anything in many ways, but you need to verify what you've modelled is according to measured real world data. Commented Apr 26, 2017 at 4:51
• @Koyovis This is not what the question is asking. For laminar flow, you'll find that it is very easy to match computations with real world data; the question is asking why this is not the case for turbulent flow. Commented Apr 26, 2017 at 19:55
• @ Sanchises. Yes indeed. And real flight has vast regions of aircraft skin with turbulent boundary layer. In an airliner in cruise flight, transition from laminar to turbulent for the fuselage is right behind the cockpit, as sound measurements show. Commented Apr 26, 2017 at 22:40

Laminar flow is easy. While there is a complete set of differential equations that describes any fluid flow, there is a wealth of simplifications and assumptions that you can use on laminar flow. This means that X-Plane doesn't need to model all the air around the wing, but can do the calculations based on wing profile and local velocities. Everything is relatively linear, so you can just change some variables and use predetermined parameters. Furthermore, it's completely time-invariant in steady state. You can now easily solve the equations, integrate the calculated pressure profile along the wing, and done!

For turbulent flow, none of that holds. The current way of simulating turbulent flow is to do a Finite Element analysis or similar (e.g., FDM). Basically, you will need to consider all the air in a large volume around the wing, divide it up in a small grid and simulate it. For a good calculation, this takes in the order of seconds to minutes for a single 2D cross-section on my pretty decent laptop. And then we're neglecting the 3D influences. Furthermore, turbulent flow changes w.r.t. time. For example, open your car window on the highway - you will hear the wind roar and pulsate. This means that you will need to get your previous pressure- and velocity field, and use that as a starting point for your next FEM/FDM analysis. Finally, turbulent flow is extremely hard to predict correctly, even with above methods: a slightly rougher surface, a small bolt or a small wind gust can delay flow separation for a few inches, completely invalidating your results. Perhaps this YouTube video (note: this is not simulated in real time!) might shed some light on the vast complexity and time-dependency of turbulent flow - and remember that your horizontal stabilizer will see disturbed air in stall conditions, making it necessary to simulate the entire flow field around the airplane for a correct simulation, not just the wing sections.

Of course, X-plane has a framerate measured in frames per second, not frames per hour. This means that they use a bunch of assumptions to calculate the wing lift. I'm guessing they just have some values for location of flow separation and turbulent pressure for some fixed velocities and angles, and interpolate to the actual values. My guess is that they also have some parameters that aren't actually calculated, but are chosen such that some very basic maneuvers are possible like spin recovery, regardless whether these values correspond to any actual physical phenomena - it's a game, after all.

• What about purpose-built simulators? Do they simulate stall conditions any better? They aren't run by supercomputers after all.
– GdD
Commented Oct 6, 2015 at 12:06
• My best guess would be that purpose built simulators just have a lot more extensive lookup tables based on windtunnel tests, but these are quite expensive and probably not public domain. Commented Oct 6, 2015 at 13:11
• Within a certain envelope, the professional simulators match a set of measured data quite well. In fully developed stalls this is no longer the case. Commented Apr 26, 2017 at 4:31
• @Koyovis Indeed, that would require putting aircraft in fully developed stalls in a wealth of attitudes, which is not really something you want to do (especially larger aircraft) Commented Apr 26, 2017 at 8:35

Because real airflow is not 2D laminar.

Not sure how far along we are with 3D turbulent flow CFD at lower angles of attack. But with high angles of attack the airflow separates from the stream body and creates a wild and random pattern of flow fluctuations - not the best candidate for CFD.

Level D full flight simulators must match a set of data that is measured on an actual aircraft. This set of data is around reasonable flight conditions, such as usually encountered during airliner revenue flights, and including most emergency situations that pilots are trained in.

Pitch AoA is measured between about -2º to stall onset, about 25º. and +/- 15º of sideslip, but not at combinations of extreme AoA and sideslip. The region that is measured during flight tests looks like the green are in picture underneath, which are the flight states in which Level D simulators must very closely match the flight data:

The blue and yellow boxes are interpolations and extrapolations of the table lookup data used for the Acceptance area. This is sufficient to train entry into stall, but not sufficient to train recovery from a fully developed stall such as what happened with AF 447. The FAA will introduce a requirement that pilots train recovery from a fully developed stall, and Airbus and Boeing are working on updating their data packages.

Some data of crashed aircraft flight recorders and wind tunnel data have been used to model stall behaviour of different aircraft types (low wing, T-tail etc), and the first simulators are already operational that can train this. Alaska Airlines has one.

• Please add a source for your images. and personally I find it a bit unintuitive to read, it almost looks like it is saying that the loss of control is inside the red perimeter, while it obviously is outside (and why is it asymmetrical?) Commented Apr 26, 2017 at 8:50
• Yes - it's sales information from a company that specialises in flight characteristics out of the normal envelope. The green bit is very extensively measured & tested. A stall approach exercise takes place in the red envelope, starts at 45 deg AoA 20 sideslip and successfully ends at 0,0. Meanwhile we've crossed interpolated and extrapolated data, so how valid is our training? An illustration of why we need full 360 degree data if we want to train fully developed stall recovery - but the industry only moved there after Air France 477 and Air Asia QZ8501. Commented Apr 26, 2017 at 9:55
• There's a lot I don't understand about that diagram. What does the red dotted curve indicate? Is it the boundary of some region or does it show a path which is traced during some process? What does "acceptance" mean in this context? Commented Apr 26, 2017 at 19:56
• @ Tanner Swett yes indeed, I'll update the answer. The dotted red line is indeed an exercise trace. Acceptance is the region where flight simulators must demonstrate how tthey match actual flight measurements.. By necessity the measurements are taken within boundaries of normal flight. Commented Apr 26, 2017 at 22:30

I cannot answer for which CFD model (or strategy/mix thereof) is used by any of the flight simulators.

I can say that CFD, in general, is more limited by available resources (FLOPS, and time) than it is about precision. At least, this is the case for a variety of situations in which most flight simulation occurs.

Realtime flight simulation (today) must make use of shorthand 'parameterizations' of the simulation grid, in order to resolve model forces at the FPS of the user experience. If the COU (and potentially the GPU) could perform more ops, then the simulation grid could use boxes that are smaller – thus higher resolution and more accurate.

Higher spatial resolution simulation grids, along with higher temporal resolution grids, are able to better capture small flow defects. These lead to changes in the flow topology, compression waves, boundary layer separations, and other more complex nonlinearities.

• There is an extensive set of actual flight data required for a professional flight simulator, which must be precisely matched in order to certify the device. FLOPS is not really a problem anymore: a full set of physics models for a Level D sim can run @ 3000 Hz on a simple laptop, while only 100 Hz is required. Commented Apr 26, 2017 at 4:48
• @Koyovis The question is asking about a simulator using CFD rather than model-based physics. Commented Apr 26, 2017 at 19:53

I'm sorry, I can't answer the physics part. It may be a good question on Physics StackExchange.

On a programming point of view (SuperUser ?):

• Floating points calculations are among the most CPU intensive.
• Precision matters when you talk about physics behaviour. Without enough precision, some parameters may jump from one value to an exaggerated one, even to the opposite value (stackoverflow), even if it's the next available value that can be stored in bits. All a computer can do are approximations.
• Cycle update/refresh cycle, or interval duration between states changes in physics parameters. 10 milliseconds may look really small and good at simulating physics properties. However, bring the aircraft in stall conditions and you realize that 10ms is not enough to accurately resolve all surface components efficiency on a normal computer. That's why on some simulator, especially the old ones, you have unexpected aircraft behavior like brutal rolls/pitches/yaws.
• Race condition. This is a situation of concern on parallel tasks made by the computer. Simply put, one task is to calculate vector forces applied on the aircraft. Another parallel task is user or autopilot inputs. And another task is to generate new airflow conditions, like gusts and turbulences. Those are not synchronized. The more the tasks, the othen asyncronuous computations occur.
• A computer just does what it has been taught to do. The aircraft can break if the value of one parameter goes beyoud a certain limit, and a brutal overreaction is induced by one miscalculated parameter (due to the refresh cycle above, or obsolete parameters due to the async multi tasks) Some damping fallbacks checks can be added in the code (like on computer driven pilots inputs), but this also add more computations to perform on user computer where the simulator is installed.
• Random update. To make turbulences for instance, you have to create dynamic random parameters whose bounds changes depending on weather conditions, altitude, geographic locations, etc. This adds to the overall computations to perform.
• By the way, the simulator has to render graphic datas on screen and handle thousands objects with millions of parameters. That's also why, unlike X-Plane of FSX/P3D, real professional simulators doesn't care much about sceneries objects (traffic) and other eye candy like clouds beautifulness or sun glare. Because physics computations are prioritized.

It's not that the datas are corrupted or miscalculated. They are 1) approximations as results of very simplified formulas or lookup tables/matrices to speed up computation time, and 2) are not always updated at the very moment they are most required (high AOA) because of excessive task to perform to update them. Adding a parameter (like an extra wing fence above the wing) and computations to perform on each update may increase linearly or exponetially. The physics model is not incorrect, but is not the most accurate one either.

In the end, one can get near to the best possible approximation, but at the cost of computation time. We often hear a computer took x weeks to calculate y trillions decimals of Pi, or z days to display an accurate overview of our galaxy colliding with M31 Andromeda. Getting there is possible, but not yet through mass public simulators like X-Plane, FSX or P3D. Common computers are not powerfull, fast and precise enough yet, to reproduce realtime physics behaviors that complex like aerodynamics or gravity.

• Race conditions do not make sense in this context. They refer to a bug when it's assumed that a value is not yet modified when it actually is, not having a 1/60 second delay in your autopilot input because the new position vector is not yet calculated.As for turbulent flow, the physics model may actually be incorrect (and not just 'not the most accurate'), because a decent approximation would be too resource-intensive, or simply not yet researched for a specific wing profile. Commented Oct 6, 2015 at 10:38
• @sanchises: Noted, thanks. Though, on a n-body object problem we had some years ago, no matter how we splitted the threads, it was impossible to get the required datas in time (matters of split seconds) We even tried performing the task on a second computer, but hardware limitations worsen it. Yes it's a bug in the way the target result was impossible to reach in time. Solution was to sacrifice parameters to kill the delay, and it's in that way I underlined the fact models are indeed wrong in the first place, I agree, but acceptable in a certain extend (lambda computer vs dedicated ones) Commented Oct 6, 2015 at 12:21
• Ah, like so. I'm still not sure that's called a race condition though. But either way, it will indeed slow your simulation unacceptably. We'll just wait for Moore's law to catch up :) Commented Oct 6, 2015 at 13:06
• Cloud and weather simulation are in integral part of Level D simulators, projected on collimated mirrors with an uninterrupted view of 200 deg H x 40 deg V. Update rate 60 Hz. Have you ever been in one? Commented Apr 26, 2017 at 6:06
• Floating point performance is not an issue at all, the complete physics model of all systems, aerodynamics, flight dynamics, ground reactions, engines etc etc can easily be computed at 2000 Hz by a simple modern laptop. The graphics is the bottleneck. Commented Apr 26, 2017 at 6:09