How actually plausible is FS9 physical model?

[Murmur 3,941]

I noticed that under some circumstances, aircraft (and helicopters) in FS9 can develop a strange behaviour that seems to violate basic physics laws.I managed to achieve it on RealAir SF260, default Bell206 and Dodosim Bell206.Basically, when the SF260 is in a very unusual part of the envelope (very low speed, high angular velocity around more than one axis, and subsequent very high AoA), it starts to exhibit a very strange flight path, with very sudden and sharp changes of direction (sort of a Brownian motion), with extended periods of climbing in very unusual attitudes. This can further develop in an unsteady but continuously climbing path, with high angular velocities of the fuselage. ALL of this with engine not running at all.I achieve an analogous behaviour with helicopters, after the engine and main rotor have stopped, and the helicopter has developed high angular velocities. It starts an implausible motion (quasi-circular paths etc.), that can later develop in a semi-steady motion with, again, high angular velocities, while rapidly climbing, eventually reaching the 100.000 feet limit!Obviously, realism settings are at max. FPS are reasonably high (40).I acknowledge that FS9 does very well on many but most unusual flight envelopes, and actually even in extreme manoeuvres (e.g. spins and alike in RealAir a/c's).But that is not my point. The fact is, I find the aforementioned behaviour flawed in a more "deep" manner, than e.g. aerodynamic under-modeling or simplifications that are of course present in all simulators.Please note I'm not bashing MSFS (it's the only flight sim I currently use), I'm just a little perplexed about what I've found and very interested in knowing your opinions.Ciao! :)Marco

[Guest _FSAviator_]

Your question is answered fully within a submission to the American Institute of Aeronautics and Astronautics which may be downloaded here. http://download.microsoft.com/download/1/7...h_Zyskowski.pdfTo summarise, the several retail Flight Models (FMs) in each version have intentional omissions, but strictly speaking no errata. Some of the content is high fidelity and some lower fidelity. The product of some included equations are approximated by use of look up tables which deliver segmented rather than smooth curves of the given function. The two generic helicopter FMs are of lower aerodynamic fidelity than the fixed wing FMs having been in development for less time. Each FM is generic for an engine type and/or supersonic data inclusion. Your question is fully answered above, but it is somewhat misdirected. I believe what follows probably also applies to the two generic helicopter FMs, but strictly speaking it addresses only the fixed wing case. Each generic FM has no code relating to characteristics that differentiate one specific aircraft, specific aero engine, or specific airscrew from another. The aircraft, engine and airscrew specific data are by custom and practice referred to as the Flight Dynamics (FD). The behaviour you witness does not emanate from the Microsoft FM. It is the consequence of less than fully detailed painting of some dark corners of the FD envelope whether the FD were supplied by Microsoft or a third party. Microsoft or third party supplied FD can potentially utilise all of the content of the relevant generic FM, but that is not obligatory. Nor is it the norm to include within the aircraft / engine / screw specific FD all of the variables, or even all of the equations, included in the relevant FM.There are three principle reasons why this is so.1) Target ConsumerWhether FD are to be payware or freeware they have a target consumer group. A payware producer may need to target a wide market segment. The producer may wish to accommodate the needs of the type rated pilot, who may explore every corner of the envelope, but sometimes the code that would best meet that experienced user

[Guest Ron Freimuth]

>I noticed that under some circumstances, aircraft (and>helicopters) in FS9 can develop a strange behaviour that>seems to violate basic physics laws.>Basically, when the SF260 is in a very unusual part of the>envelope (very low speed, high angular velocity around more>than one axis, and subsequent very high AoA), it starts to>exhibit a very strange flight path, with very sudden and sharp>changes of direction (sort of a Brownian motion), with>extended periods of climbing in very unusual attitudes. This>can further develop in an unsteady but continuously climbing>path, with high angular velocities of the fuselage. ALL of>this with engine not running at all.>Marco I've seen things like that with the Concorde. I think it's due to the FM iteration rate being insufficient to iterate over small changes in the state of the flight model. Thus, an AC may fly in straight line segments, rather than along a smooth trajectory. Once in this state, the basic physics isn't correctly calculated. AC can climb with zero throttle, etc. It is probably common in other simulators, but just how it shows up depends on details of the DE solver, if the iteration rate is varied, etc. -- I just DL'ed the MSFS FM description from the URL in Warren's reply. I see MSFS iterates the FM only 16 times per second, doubling to 32 Hz at times. JSBsim, used in FlightGear has a user settable rate, and 120 per second is typical. Problems with small pauses, etc. also tend to mess up the DE solver, an AC may jump up in pitch in steps, rather than smoothly, over short periods of time. Other simulators typically don't display such behavior. Ron

[Murmur 3,941]

> I've seen things like that with the Concorde. I think it's>due to the FM iteration rate being insufficient to iterate>over small changes in the state of the flight model. Thus, an>AC may fly in straight line segments, rather than along a>smooth trajectory.>> Once in this state, the basic physics isn't correctly>calculated. AC can climb with zero throttle, etc.Yeah, I agree with you. I think this two passages from that MSFS paper are related to the subject:(Delta T)"Combat Flight Simulator utilizes a fixed ΔT of 16Hzthroughout the entire application. We discovered,however, that DURING CERTAIN HIGH-DYNAMIC MANEUVERS,NUMERICAL INSTABILITIES EXIST when attempting tosimulate aircraft at this low a frequency. We thereforeincorporate a doubling of certain SimEngine runtimefunctions to halve the ΔT

[mgh 89]

I think you've misread the paper. It's only Combat Flight Simulator that uses 16/32Hz. Flight Simulator adjusts its rate in accordance with a frame rate achieved. (I've never used Combat Flight Simulation but it would seem it runs at 16 or 32fps?) In any event that rate has to match the computing load, so there is no point in setting a rate higher than a computer can process at any given time.Using the notation of the paper, deltaT is the time slice being simulated - ie the simulation is advanced in real time by deltaT. This will take a certain amount of processing time as the computer updates the aircraft, the AI aircraft, the scenery, the terrain, the clouds, the instruments, the clouds etc as well as generating the display. The processing time, deltaH, has to be the same as deltaT otherwise the computer would run faster or slower than real time and get completely out of step with real time.One way to achieve this that Microsoft might have adopted is to start an internal timer at the beginning of each computing cycle and stop and restart it at the end of the cycle. The resulting time interval would be deltaH for that computing cycle. The time slice deltaT could then be set equal to deltaH for the next cycle and so on, with deltaT being continuously adjusted. This would result in frame rates varying with the amount of computation that needs to be done at any particular instant. The frame rate would become 1/deltaT. That would be a fairly simple approach and I'm sure Microsoft has refined it a good deal. Refinements include prioritising variables by the speed with which they change and not calculating the slower moving ones every cycle etc.