Salut ydelta,

Belle contribution. Quelques remarques.

Calculer la portance c'est facile : c'est la masse fois le facteur de charge. Ensuite avec q et S on déduit le Cl.

Mais comment MSFS calcule la traînée directement sans utiliser le Cd? Impossible.

La différence de Cd dans ton exemple en valeur peut sembler faible, mais si on fait le calcul c'est environ 776 lb de traînée qui manquent... Ça fait 11% de 6922, ça fait beaucoup...

La valeur other_drag est faible si l'avion est dans l'enveloppe qui correspond au Cl0 dans le SDK.

Mais fait l'essai : regarde sa valeur en croisière et regarde sa valeur en vol lent (green dot, à faible altitude). C'est toujours du vol stabilisé mais la différence avec la polaire théorique devient vraiment trop importante...

Salut Ragg Sor,

En l'occurrence, l'état de l'art est plutôt bien complet et les formules en question sont bien comprises et utilisées pour les calculs de performance.

Au final, les propriétés atmosphériques importent peu puisqu'on peut les faire varier avec les paramètres qui vont bien (theta, delta et sigma pour les connaisseurs).

Ce que je veux dire par là, c'est que peu importe qu'il fasse 15°C ou 30°C, que le QNH soit de 1025 au lieu de 1013, tout cela est pris en compte dans les formules et les performances calculées sont bonnes.

Le problème, c'est ce que Filoux a expliqué au-dessus : rustine sur rustine. Un ancien instructeur disait "peinture sur merde, ça reste de la merde".

Quant au fait que le SDK décrive quelque chose et que MSFS fasse factuellement autre chose, et que l'on sache pas quoi exactement, voilà pourquoi cela demande autant d'efforts pour reproduire quelque chose qui ne devrait même pas être un problème.

Un autre exemple de truc bien foireux : la variation du fuel flow d'un jet en fonction de la densité. Il y a une formule connue et acceptée, le SDK donne même la référence d'un article scientifique qui la mentionne. Et bien au lieu d'appliquer cette formule qui ferait varier le fuel flow avec le nombre de Mach, les développeurs ont décidé de mettre un table toute pourrie en fonction de la densité. C'est aussi pour ça qu'à la sortie, les jets avaient le même fuel flow en croisière au FL370 qu'au niveau de la mer...

Bref...

Je me demande si l'âge du Capitaine n'a pas non plus une influence. A ce stade, pourquoi pas ? ?

C'est quand même pas sérieux que le simulateur ne reproduise pas une formule aussi simple...

Une solution serait une table drag_coef_aoa et le tour serait joué.

Je vais poster l'idée sur le forum devs, on va bien voir ce que ça donne...

Salut,

On me mentionne alors je me permets d'ajouter mon grain de sel à cette passionnante conversation sur les modèles de vol...

Le problème de MSFS est dans le calcul du Cd0, et je vais reprendre le screenshot de Filoux pour le montrer.

On peut voir que MSFS fait varier la valeur de Cd0, qui devrait être une constante définie dans le fichier flight_model.cfg, et lui retranche une énorme valeur de 0.0130 environ, ce qui fausse complètement le calcul de la traînée...

D'après la même fenêtre, c'est le fait que la profondeur soit en position non-neutre qui justifierait cette différence de traînée... Bon, j'avoue que j'ai pas bien compris le concept de commande qui ferait de la traînée négative mais bon... Je ne prétends pas tout savoir non plus...

Du coup, il faut faire des choix, soit avoir la bonne traînée en croisière, soit à basse vitesse. Mais pour l'instant je ne crois pas qu'avoir les deux soit possible...

Je comprends Filoux lorsqu'il dit que JSBSIM c'est mieux. Et je suis bien d'accord.
A force de vouloir réinventer la poudre, on a un machin pas bien fini qui fait un peu ce qu'il veut.

Petit test marrant à faire pour ceux qui le souhaitent. Faire bouger les commandes et regarder comment la polaire réagit dans la fenêtre de debug drag.

Cette histoire de "remise" me rappelle quand même quelque chose...

Extrait de l'AFM :

J'en profite pour corriger mon précédent post, ma mémoire défaillait.

La carburant passe du réservoir gauche, au moteur par le réservoir droit puis retourne dans le gauche, et ne se vide pas dans le droit.

Le gauche se vide au cours du vol et le droit sert à alimenter le gauche et à équilibrer les masses.

Lien vers l'AFM (version TDI) pour les curieux : http://support.diamond-air.at/da40-tdi_ … 73ab0.html

Le simu, normalement les altitudes viennent codées dans la procédure. Mais tu peux les ajouter en regardant la carte d'arrivée et en entrant les altitudes sous ce format : altitude/ et en sélectionnant la bonne ligne.

C'est parce que tu utilises la version par défaut. Je te recommande le mod par Heavy Division, qui le fait ressembler un peu plus au vrai.

Pas besoin de plan de vol pour la lancer à l'eau : normalement, dans le fichier flight_model.cfg, tu peux régler le paramètre spawn_cruise_altitude à 0 et normalement, elle devrait être au niveau de la mer. Plus qu'à cliquer sur une zone aquatique avant de lancer le vol et ça devrait marcher.

Bon, suite à la réponse de FlyingRaccoon, il semblerait que ne soit finalement pas un bug, mais une mauvaise présentation des résultats de la fenêtre du debug tool.

En effet, la valeur Total NEW ne correspond pas au Cd0, mais au Cd(alpha = 0), soit Cd0 + Cdi pour un angle d'incidence égal à 0.

J'ai cependant remarqué que mettre une valeur de 0 pour le induced_drag_scalar enlève la traînée dûe au train d'atterrissage (voir les résultats du DA40NG).

Merci à tous pour votre aide!

Pour ceux qui demandaient des explications : je vous invite à aller les lire les liens suivants :

https://fr.wikipedia.org/wiki/A%C3%A9rodynamique

https://fr.wikipedia.org/wiki/Tra%C3%AEn%C3%A9e_induite

Dans le cas de MSFS, la traînée induite a une influence sur la traînée parasite, ce qui ne devrait pas être le cas.

Merci pour cet avis de professionnel!