The title of the post is very stimulating and for this reason I want to contribute to this discussionI don't know if my contribution can give some useful advice to the discussion, but it comes from my experience in building the FDM of the FIAT G91R1B project.
When I started the FIAT G91R1B project (
https://github.com/abassign/G91-R1B_HD.git ) I had done some checks on the two FDMs currently present in FGFS, the first YASIM that I found nice, but then, looking at the code, I verified that it consisted of the FDM dynamically using software derived from the philosophy of known Datcom (
http://wpage.unina.it/agodemar/DSV-DQV/Digital_Datcom_Users_Manual_1.2.pdf ) which is a program that calculates the aerodynamic tables of an aircraft according to its geometry and flight envelope. This approach is useful for making airplanes with simplicity (something like this was used by X-Plane), but without paying particular attention to the real characteristics of the aircraft.
Datcom is certainly useful for building the base tables, but then these must be further elaborated on the basis of real data. A real plane has an aerodynamics that often moves away from the one theoretically calculated by a simple program like Datcom, it would be necessary to use other fluid-dynamic simulation programs to obtain more exact tables. The best thing would be to have the aerodynamic tables made in the tests of the real plane, but it is rare to own such tables. Therefore Datcom (and therefore YASIM) can be used to obtain a plane that performs a flight close to the real plane, but certainly not to get a plane with flight characteristics close to the real one. If you complain that an FGFS plane, in flight, is not similar to the real one ... we don't have to complain about the FDM used, but the data used to configure the FDM!
Obtaining the data necessary to correctly configure our FDM (I use JSBSim not YASM, but it is the same problem) it is necessary to perform hundreds of flight tests. For example, I had to do a lot of tests on the engine down rate (efficiency) which is a great way to understand the aerodynamic efficiency of the aircraft, I had to do (me and other friends of this adventure) many tests to get something like this real. For brakes, I had to use force vectors directly, using the JSBSim tag:
external_reactions which allows you to get enough fine control over the forces that apply to the aircraft. For example the airbrakes have been simulated in this way and finally I realized that for the G91R1B they are not particularly effective, but due to their position far from the center of gravity they tend to modify the trajectory, this is also true for the landing gear etc.
So if we want to get a model close to reality, we have to work a lot with successive refinements, until we get what we think is the real plane, the FDM is simply an engine that interprets what we insert and not a "magic wand" that calculates from a 3D drawing the behavior of the real plane.
Go beyond JSBSim, YASIM and NASALCurrently FGFS has two FDMs, the system XML and a NASAL scripting language. This fact confuses a little and makes it difficult to make a model close to reality.
For example for the G91R1B I had to realize in NASAL a sort of robot for piloting the plane, this rather complex module (I've been working on it for three months) allows me to be able to test the aircraft in various phases of flight and figure out how much I'm really close to reality. NASAL and JSBsim with the system XML as a glue are quite powerful, but there are three different ways to program! I use JSBSim when I want to simulate a real device (for example an on-board system, the electrical system, erodynamics etc ...) with a simple code to maintain and light in its execution, while I use NASAL when I want to simulate the interaction of the aircraft with the pilot and the external environment for which the frame rate can be quite low (1-10 fps).
My desire would be to be able to have a single programming environment, always with a data-driven functional philosophy (which is followed by JSBSim ... even if with some limitations) and not using NASAL and limiting the system XML only for interface with 3D objects.
For this reason I am studying various functional languages (python leave at home please ... it is absolutely not easy to program and maintain in data-driven / functional mode!).
I am currently exploring Haskell which is a pure functional language which actually eliminates loops (like JSBSim) and the variables are static and therefore does not pose particular problems in concurrent programming, an essential fact in systems simulation.
I hope soon to write a simple FDM in Haskell to understand if this approach makes sense and therefore to replace with Haskell also NASAL, for this it is enough to make a binding in C ++ (as it was done for JSBSim) and try. The nice thing is that Haskell has a very efficient and fast compiler that creates a pure C-code which, if written well, has the same speed as the equivalent C code. My idea is to be able to create the modules in a single language and integrate them, through the system XML, directly into the folder of the aircraft without penalty in performance and possibly working in a multithreaded way with transparency and effectiveness and a high isolation to allow have an effective multi-user and not too limited like the current one.
Obviously mine is only a search for a solution, an exercise to understand, but I hope that over time we will all find something useful that can renew the current work approach.