Jump to content
Sign in to follow this  
MorsAbAlto

How much more can FSX handle? (be warned, lots of opinion)

Recommended Posts

 

 


Coefficients of lift, drag, pitch, etc aren't physical quantities, so you might not recogise calculating them as "physics based". All a data table does is calculate them from inputs such as angle of attack, sideslip and Mach number. Then you can calculate lift, drag, pitching moment, etc and use these forces and moments in the simulator's equations of motion. What isn't physics based about that?

I think this says just about everything that needs to be said about your understanding of the issues.

You are right, coefficients are not physical properties, though they are often used to describe the interaction between physical bodies.

You are wrong. Look-up tables do not calculate coefficients, just as they don't calculate anything else. A look-up table is a table of keys with corresponding values. When given a key, it looks up its table to return the corresponding value. No calculations. No physics. Just a lookup. Of a table. Hence the name, lookup table.

 

Now if you wanted to say that physics was done and calculations were performed to determine which values went into the look up tables, you might have had a valid point, but since those values could just as easily come from wild guesses that were tweaked to make the simulation behave a bit like the real thing, and you have no evidence either way, you are stuck with the simple truth; Using lookup tables is cheaper then doing it properly, and two decades ago, we couldn't afford to do it properly.

 

You also have to admit that finding the best values to use in a lookup table is done in exactly the same as finding the best values to use for a 3d shape: by using your best effort. And if one is doable, why wouldn't the other be?

 

I have no idea what you meant to say with the words: "The flight test data provided by aircraft manufacturers doesn't support that approach". The flight data is the result of the physics of the aircraft. The numbers are neither magic nor made up, and the physics of flight is well understood, so I do not understand where exactly, as an aeronautical engineer, you have a  problem?

 

A final question for you. Why do you think lookup tables and fluid dynamics are a) mutually exclusive or b) the only two options? I am sure that you agree that a physical force calculated from first principles will be never be less accurate, and can sometimes be more accurate, then one taken from a table, so if one force were to be calculated, even if the rest remained lookup, the result would be a sim that was no worse, and might be better. Between lookup tables and CFD are many other options with greater (and lesser) amounts of physics. The blade element theory used by X-plane is an excellent simulation of the physics of aerofoils, even if it is still a simplification. CFD projects like NASA's Overflow are beginning to come on-stream, but as you say, are probably overkill in the entertainment area. Numerous solid body simulations exist in various game engines, though most concentrate on the kinetic simulation and skip potential energy (which means they have no gravity and no momentum!) but a few game engines are making progress in partial or full energy management simulations.

Share this post


Link to post

I think this says just about everything that needs to be said about your understanding of the issues.

I'm getting rather tired of you saying I don't understand this. I'm a professional aeronautical engineer and I've been active in the commercial flight simulation industry nearly 40 years. Most of that time I've been producing flight and propulsion systems simulation software and qualifying flight simulators for airline use. I know a lot more about this subject than you think you do. The structure of the flight model in FSX is far more closely related to Level D full flight sims than that in X-Plane is. It's much less detailed than a Level D FFS of course which is where the inaccuracies arise, but the principles are the same.

 

CFD is great for estimating how a new aircraft design, winglet mod, etc, will perform. So accurate now that aircraft fly almost exactly as predicted from the first flight these days. But once you have flight test data to work with CFD performance predictions are a very awkward sledgehammer to crack a walnut. The coefficients and derivatives in a "lookup table" flight model aren't estimates. They are produced by analysis of flight test data, in other words how the aircraft actually performs.

 

You are right, coefficients are not physical properties, though they are often used to describe the interaction between physical bodies.

You are wrong. Look-up tables do not calculate coefficients, just as they don't calculate anything else. A look-up table is a table of keys with corresponding values. When given a key, it looks up its table to return the corresponding value. No calculations. No physics. Just a lookup. Of a table. Hence the name, lookup table.

 

Now if you wanted to say that physics was done and calculations were performed to determine which values went into the look up tables, you might have had a valid point, but since those values could just as easily come from wild guesses that were tweaked to make the simulation behave a bit like the real thing, and you have no evidence either way, you are stuck with the simple truth; Using lookup tables is cheaper then doing it properly, and two decades ago, we couldn't afford to do it properly.

 

You also have to admit that finding the best values to use in a lookup table is done in exactly the same as finding the best values to use for a 3d shape: by using your best effort. And if one is doable, why wouldn't the other be?

In aerodynamic terms a coefficient is a dimensionless force or moment. It isn't a simple multiplier like a friction coefficient, for example. You don't appear to know how lookup tables work either. They don't simply look up the result at specific key points, not even the ones in FSX. They interpolate between data points too. They are more precisely called function generation tables. The more data points used, the more precise the output. You can use polynomial fitting methods too for even smoother results but they are less convenient to use for almost no extra gain in accuracy. It's called mathematical modelling. But it models forces and moments just like a CFD based model does.

 

The coefficients and derivative functions aren't estimates. They are produced by the flight data analysis engineers at the aircraft manufacturer.

 

I have no idea what you meant to say with the words: "The flight test data provided by aircraft manufacturers doesn't support that approach". The flight data is the result of the physics of the aircraft. The numbers are neither magic nor made up, and the physics of flight is well understood, so I do not understand where exactly, as an aeronautical engineer, you have a  problem?

Flight test data comes from flight tests believe it or not. Boeing does these tests to certify the aircraft for service and facilitate qualification of simulators produced from their data. This is the method mandated by bodies such as the FAA and EASA. Even if you did somehow independently produce a CFD based flight model it would still have to be validated by comparison with flight test data. The best way for sim manufacturers to be sure their models will match flight test is to use the same flight simulation model the manufacturers use. And that is what is supplied by Boeing, Airbus, etc for the purpose. As I said to you before, fine tuning a 3D model in a CFD simulation to match flight test data would take a great deal of time, analagous to the work that goes on in developing a new aircraft. If you have a model based on aero coefficients and derivatives then you can easily isolate the part of the model to be adjusted.

 

A final question for you. Why do you think lookup tables and fluid dynamics are a) mutually exclusive or B) the only two options? I am sure that you agree that a physical force calculated from first principles will be never be less accurate, and can sometimes be more accurate, then one taken from a table, so if one force were to be calculated, even if the rest remained lookup, the result would be a sim that was no worse, and might be better. Between lookup tables and CFD are many other options with greater (and lesser) amounts of physics. The blade element theory used by X-plane is an excellent simulation of the physics of aerofoils, even if it is still a simplification. CFD projects like NASA's Overflow are beginning to come on-stream, but as you say, are probably overkill in the entertainment area.

I never said CFD and data tables were the only two methods. You are putting words into my mouth. They are main two options though.

 

How do you imagine the X-Plane aerofoil models produce lift, drag and pitching moment values? It certainly isn't CFD. It isn't magically produced from the aerofoil shape either. It comes from data tables based on published aerofoil characteristics. Lookups.

Numerous solid body simulations exist in various game engines, though most concentrate on the kinetic simulation and skip potential energy (which means they have no gravity and no momentum!) but a few game engines are making progress in partial or full energy management simulations.

Anything that ignores potential energy is hardly physics based, is it? At least FSX doesn't do that. I think people would be surprised just how much physics FSX does take account of.


ki9cAAb.jpg

Share this post


Link to post

Why is this still an argument...?

Beats me. But if I'm accused of not understanding something I must reply.


ki9cAAb.jpg

Share this post


Link to post

Despite the tension that is now filling this thread, the argument is rather interesting. 

Share this post


Link to post

Quote system isn't working..... grrrr :)

 

Kevinh

"It isn't magically produced from the aerofoil shape either. It comes from data tables based on published aerofoil characteristics. Lookups."

 

You sure abut that? Wasn't that the whole point of xplane? Rather than tables it uses the model shape, that's what they have been telling us for years. It is a combination of model shape tweaked with scripts.

Unless the whole thing is a lie.

 

Personally I don't care which method is used. If a Dev is good enough then the aircraft will behave like the real one.

Chris

Share this post


Link to post

Sort of.

 

Seems to me that underneath all the boasting that they actually agree on more things than they disagree on but can't see it due to the trees getting in the way of the forest.

 

Your average joe probably doesn't care or even fully appreciate the detailed mathematics that go into any decent flight simulator- but whether or not we're using the power of GPU to wind-tunnel an airfoil in real-time or simply making interpolations on the CPU between data values in lookup tables, what we all are really clamoring for is a larger degree of realism and fidelity in the flight model.  How that gets accomplished under the hood won't matter to most, as long as they NAIL it.

 

We'll know that day has arrived when all the default planes get realistic spin, stall, and high-altitude dynamics that behave like the real planes they are simulating.  The icing on the cake?  How about detailed crash physics that gives us something in-between a "bounce to a stop" or a "screen freeze with the text 'crash'".

 

The algorithms and data structures that pull this off are simply software engineering arguments and I've had many professional differences in opinion with others in my field on how to accomplish even the simplest of tasks.  Over the years I've realized that given that the majority of the life of a piece of software will be spent in maintenance mode, the best decision on how to write the code is often the one that lends itself to ease of future modification though code modularity (well insulated and plug and play type functions/procedures).

 

Mark Trainer

Share this post


Link to post

Quote system isn't working..... grrrr :)

 

Kevinh

"It isn't magically produced from the aerofoil shape either. It comes from data tables based on published aerofoil characteristics. Lookups."

 

You sure abut that? Wasn't that the whole point of xplane? Rather than tables it uses the model shape, that's what they have been telling us for years. It is a combination of model shape tweaked with scripts.

Unless the whole thing is a lie.

 

Personally I don't care which method is used. If a Dev is good enough then the aircraft will behave like the real one.

Chris

 

True like for like representation requires numerical simulation which is only ever as accurate as the numerical model used amongst other factors. In my days at university doing this kind of research you wouldn't believe how much we do not know. We still don't understand things like turbulence, not the bumps type of turbulence but the chaotic and turbulent nature of an airflow that occurs at tiny scales. With research projects like this being financed and achieving these 'acceptable error' type results, will a $60 simulator like X-Plane seriously simulate all of this accurately in real time? If it did we would be using it extensively in industry and saving a lot of money that is for sure!

 

Level-D simulators do not use such methods because they are not required for that purpose - simulators are there to simulate and by simulate they aim to replicate the flight envelope that pertains to that particular aircraft through actual test data. Normally this test data is a complex exercise of doing something, seeing what happens and recording what happens. Following this you translate that data into a simulator model.

 

So in a Level-D simulator you expect to turn the stick and get the same behaviour as the real thing, I would hazard a guess that this method and however it is achieved is far more accurate than trying to simulate reality itself which we currently still cannot do despite billions of dollars of investment and research time. In essence lets not forget that accuracy is perceived and validated by comparison to real results, therefore if it flies like the real thing who cares?


Lawrence Ashworth

XhCuv5H.jpg

Share this post


Link to post

Quote system isn't working..... grrrr :)

 

Kevinh

"It isn't magically produced from the aerofoil shape either. It comes from data tables based on published aerofoil characteristics. Lookups."

 

You sure abut that? Wasn't that the whole point of xplane? Rather than tables it uses the model shape, that's what they have been telling us for years. It is a combination of model shape tweaked with scripts.

Unless the whole thing is a lie.

 

Personally I don't care which method is used. If a Dev is good enough then the aircraft will behave like the real one.

Chris

X-Plane breaks the wing down into several elements based on aerofoil sections. That way it can simulate asymmetric forces very well. Something FSX struggles with. But each aerofoil type has to have a set of data to produce lift, drag and pitching moment coefficients. It can't directly interpret an aerofoil shape to produce the output. So it uses data table interpolation. The X-Plane airfoil maker documentation it describes what data it needs.

 

Sort of.

 

Seems to me that underneath all the boasting that they actually agree on more things than they disagree on but can't see it due to the trees getting in the way of the forest.

 

You are right that Paul and I would agree on most things. The rest is semantics. He is determined to show that a data interpolation approach is not a physics based method. I contend that any maths model that produces realistic forces and moments is physics based. It all depends where you draw the system boundary.

 

I don't know about Paul, but I certainly can see the wood for the trees in this debate. I understand his position but disagree with it. I'm sorry you feel I'm boasting but i have to make it clear to Paul that I'm not making stuff up.


ki9cAAb.jpg

Share this post


Link to post

 

 


You are right that Paul and I would agree on most things. The rest is semantics. He is determined to show that a data interpolation approach is not a physics based method. I contend that any maths model that produces realistic forces and moments is physics based. It all depends where you draw the system boundary.

 

+1  Nice summation. Engineering is all about building models that mimic physics, and a good model is deeply rooted in the underlying physics.


Dan Downs KCRP

Share this post


Link to post

I didn't realize I was boasting, if so, I apologize as it wasn't my intention. I want people to agree with I am saying because they are convinced that it is correct, not because it is me saying it.

This 'debate' arose out of the difference between two assertions, 1) that flight simming as a hobby has a future based on the FSX platform, 2) that flight simming doesn't have a future unless it can simulate the physics of flight.
There is no argument that the Microsoft flight franchise is a platform dependent on lookup tables so it really comes down to whether or not lookup tables can do a good enough job to get the physics right to allow both assertions to be true. Kevin feels there is no problem here, but he has ascribed properties to lookup tables that are, in my opinion, rather generous. (I would use the term fanciful but I am trying to be polite). In particular, he contends "... that any maths model that produces realistic forces and moments is physics based." (which is of course true) and by inference, that lookup tables are, somehow, a mathematical model or can do calculations, which is ridiculous. This is something he has repeatedly suggested, and something that is fundamentally incorrect. Given a key, a lookup returns a value. If it is coded well, then given a key that doesn't match, it will return a 'best fit' guess based on the nearest matches. Kevin surprised me by mentioning the use of interpolation to get the value to use when you don't have an exact key match which is odd because it helps make my argument stronger.

<tl;dr>
For those not familiar with interpolation, say I have a lookup table with two entries; 100 is 60 and 120 is 70, and I want to know what value to use at 105. I could take the value lower value plus the pro rata difference so 60 + ((70-60)/(120-100)) * (105-100)). This is cumbersome, but it is just a complicated version of linear regression. The more traditional approach is to break it into two parts so: The equation of the line joining the points is (y-y1) = m(x-x1) where m is the slope of the line, and slope is change of y over change of x so (70-60)/(120-100)= 0.5 is the slope. Using the first point 60 = 0.5*100 +c gives an intercept of 10. So the equation of the line is y = 0.5x + 10 so if x is 105, then y is 62.5 and with those two constants, I can calculate y for any value of x, using less computing then it takes to look up a table.
</tl;dr>

If you do have a linear relationship then using y = mx + c works much better and is cheaper the using a lookup table. However, as Kevin will tell you, most of the interesting properties of flight are not linear. Even then, lookup tables and interpolation can work well if there are enough values so that there are always keys near to the probable keys you will use. Where the FSX platform falls down so often is that it doesn't have enough entries in its tables so its guesses (and that is what they are when the results are interpolated) are further and further from the mark. If you are interested, the tables are documented here: https://msdn.microsoft.com/en-us/library/cc526961.aspx

An example is that all lift and drag calculations involve air density, but air density is not a constant and varies in proportion to compressibility which is associated (in a non-linear manner) to MACH (the ratio to the speed of sound) and this gets really messy from just below to just above MACH 1. The FSX platform the offers space in its tables for 17 Mach modifiers, which sounds great until you realize that they are in steps of 0.2M. In other words, there is only one entry between a slow aircraft at M0.8, and a supersonic one at M1.2 so there is just no way to model transsonic behaviors using FSX's table lookup table based system. Point your aircraft of choice into a power dive and you have no problems pulling out. Try that in real life and you die. In the real world, when you push an aerofoil into the airstream, the airstream pushes back, causing the aircraft to react. In a physics simulation, you attempt (with simplifications) to determine how hard the airstream is pushing back and respond accordingly. In a lookup simulation, you react based on the how much you deflected the control (with some modifiers). Even when you use good physics to determine the values that go into the lookup table, a lookup based sim is not attempting to simulate the physics of the aircraft, only to emulate its behaviors, and that works fine only as long as you remain inside the emulated behavior range.

A physics based simulation will break a wing (and the rest of the plane) into smaller parts and calculate the interaction of each part and its contribution to the whole. The more resources available, the smaller the parts that can be simulated and the more frequently they can be sampled, and more accurate the resulting behavior will be (wing tip stall anyone?). A lookup based sim will simply look up the value for the plane and lookup the value of modifiers. If the values in the table are accurate and there are enough of them, it can produce an accurate result, but only as accurate as its tables allow.

Kyle, you asked why this discussion was still going on? Well it is not like there is anything more interesting to talk about around here at the moment. Would you prefer if we went back to demanding 2D cockpits and wing flex, or asking if the toilets flush?

  • Upvote 1

Share this post


Link to post

 

 


Would you prefer if we went back to demanding 2D cockpits and wing flex, or asking if the toilets flush?

 

Some days? Yes.

  • Upvote 1

Kyle Rodgers

Share this post


Link to post

HAHA!  

 

We need someone to develop a CUDA program that runs on any modern NVIDIA GPU to use its incredible parallel processing ability for sophisticated computational fluid dynamic modeling to determine the exact slant and height of the toilet water flush, and a....yes wait for it....LOOKUP TABLE to determine if the aircraft is in a northern or southern latitude to determine rotational direction!

 

This thread rocks!

 

Mark Trainer

Share this post


Link to post

That's only useful if enough cores remain to render the toilet water swirling in the bowl.


Barry Friedman

Share this post


Link to post

That's only useful if enough cores remain to render the toilet water swirling in the bowl.

Lol...well done brother.


spacer.png


 

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...