[MSFS]Fenix A320 V2

Filoux · [↑]

Boufogre a écrit :

Filoux a écrit :
...
Ma conclusion est que MSFS ne restitue pas exactement la modélisation décrite dans le sdk, ce que j’avais noté avec un autre user du nom de boufogre sur le forum de msfs, obligeant les designers à sortir des sentiers battus pour obtenir les résultats visés. Pour avoir une petite expérience de la modelisation du 320, je maintiens qu’ils ont faut un excellent travail.
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.

https://www.pilote-virtuel.com/img/members/811/Capture-d-aecran-2024-09-10-140340.png

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.

Salut Boufogre, content de te retrouver ici !
Effectivement j'ai découvert que MSFS recalculait le Cd0 avec la position des commandes de vol, mais pas que ! Le vrillage des ailes rentre également dans l'affaire.

Si ce n'était qu'un problème de Cdo, la polaire se déplacerait à l'horizontale... Donc une petite correction sur le Cd0 du cfg et le tour serait joué, mais MSFS est tordu !

Pour compléter, la trainée induite ne correspond pas à un polynôme d'ordre 2. MSFS sous estime énormément le Cdi obligeant à doper le scalaire qui va bien. Donc croire parce qu'on met les bons paramètres comme dans le bouquin permet d'avoir les perfs du manuel de vol, c'est se fourrer le doigt dans l'oeil.

Dernière modification par Filoux (10-09-2024 20:36:55)

Boufogre · [↑]

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...

Boufogre · [↑]

Voilà, donc pour illustrer le problème en détails, voilà le projet sur lequel je travaille actuellement.

La polaire est définie dans le fichier flight_model.cfg comme suit :

Cd0 = 0.014206
k = 0.04928
Cl0 = 0

J'ai plotté dans Excel la polaire fournie par MSFS avec les paramètres ci-dessus :

En bleu, on peut voir la polaire théorique, et en orange, la polaire que calcule MSFS.
Le terme -0.0232x (devrait être nul) donne comme indice que même avec Cl0 = 0 définit dans le fichier, MSFS fait comme s'il calculait un Cl0 de 0.2354. Pour ceux que ça intéresse, le calcul n'est pas difficile à faire.

Filoux · [↑]

Voila, MSFS minimise enormement la trainee induite… Cf courbe orange sous la bleue. Petit tips: Il faut que tu joues sur le wing sweep quitte à avoir des valeurs exotiques pour atteindre la courbure voulue.

Dernière modification par Filoux (11-09-2024 17:03:19)

flomartin · [↑]

J'aime beaucoup cette discussion sur le modèle de vol du 320 sous MFS, même si ça dépasse un peu mes connaissances.

Mais pourquoi diable MFS ne calcule pas les choses comme il le devrait ?

Et pourquoi diable Asobo ne corrige-t-il pas son MDV pour faciliter ainsi le travail des développeurs ?

En tout cas, merci à Filoux, Boufogre, Bee Gee et les autres pour ces échanges super intéressants !!! J'attends la suite avec impatience :)

Filoux · [↑]

flomartin a écrit :

J'aime beaucoup cette discussion sur le modèle de vol du 320 sous MFS, même si ça dépasse un peu mes connaissances.
Mais pourquoi diable MFS ne calcule pas les choses comme il le devrait ?
Et pourquoi diable Asobo ne corrige-t-il pas son MDV pour faciliter ainsi le travail des développeurs ?
En tout cas, merci à Filoux, Boufogre, Bee Gee et les autres pour ces échanges super intéressants !!! J'attends la suite avec impatience :)

Bonne question. Je pense que les devs d’Asobo ont repris le modèle d’origine en voulant l’enrichir. Le problème c’est que ce sont de bons codeurs mais pas des aerodynamiciens. Résultat des courses, en empilant les « améliorations » on arrive à un modèle non challengé en interne sur des points évidents tels que celui mentionné par Boufogre et qui s’avère être une usine à gaz sur lequel tu passes plus de temps à tordre les potards pour atteindre le résultat désiré, qu’à vraiment développer.

En plus au fil des updates tu découvres de nouvelles rustines imaginées. La liaison sol est un bon exemple…

C’est dommage car MSFS a tellement de potentiel. La porte de sortie c’est un modèle externe type JSBSIM dans lequel tu peux absolument tout faire et qui enverrait les données de position et d’orientation au simu à chaque cucle de calcul.

Majestic avait fait cela sur P3D et je pense que A2A a pris également cette option.

Dernière modification par Filoux (11-09-2024 17:13:41)

Ragg Sor · [↑]

Hello à tous, j'ai une petite question, inspirée par la lecture de vos retours, de vos expertises (en présumant que vous ne vous trompez pas)

Vu que vous êtes en train de rentrer dans des détails assez fous (pour les béotiens comme moi) pour corriger le comportement du Fenix quand il est en N-1 entre 17 et 19°C sous un angle de 22,87° avec en effet l'âge du capitaine pair et avec une humidité supérieure à 17% (pour la team premier degré, relax, vous me comprenez je pense), et vu que vu la qualité du bestiaux je pense quand même que chez Fenix ou Asobo ils sont pas complètement manchots....

La physique étant ce qu'elle est, les formules mathématiques pour expliquer ceci ou cela, pour le simuler, et la complexité de tout ça étant de faire fonctionner tout ça en même temps... Je me demande si en mettant "les bonnes formules" aux bons endroits absolument partout, que la "faute" soit chez MSFS ou chez Fenix, ou chez les deux, on n'aurait pas un comportement incohérent voire très très mauvais ?
Parce que justement, certaines interactions entre différents phénomènes physiques n'ayant jamais été modélisées, il manque un truc quelque part, parce que c'est de la simulation et que donc en l'état actuel de l'art, on n'est toujours pas au perfect de l'imitation du réel...
Et que du coup, fasse à ce constat, les développeurs doivent "bricoler" des formules pourtant correctes, les rendant incorrectes, parce qu'en testant, et bien l'avion se comporte globalement de manière plus cohérente avec la fausse formule, car ça palie je ne sais quel défaut que personne n'est pour le moment en mesure de comprendre/trouver/modéliser ?

Et que du coup, si on recentre la barre en revenant aux "bonnes" formules, et bien ça fausse le tout? Rentrer dans le détail d'une formule isolée avec des courbes et des calculs, sur papier c'est bien, mais si ça se trouve, une fois que c'est mis en musique au milieu de tout le reste... C'est là que le bas blesse.

Une hypothèse comme ça, sachant que dans plein d'autres domaines, c'est ce qu'il se passe, on a la théorie, on arrive au pratique avec un résultat pas exactement pareil parce que l'état de l'art est incomplet, et on bricole un peu, dans des marges acceptables, pour arriver au résultat désiré ?

Dernière modification par Ragg Sor (11-09-2024 17:47:30)

flomartin · [↑]

Merci Filoux pour ton explication.

Quel dommage qu'Asobo n'ait pas embauché des aérodynamiciens pour leur moteur, ça aurait évité les soucis actuels.

C'est sûr qu'empiler les rustines, ça n'a jamais été terrible. Le modèle externe est-il une possibilité avec MFS ?

Ou était-ce faisable qu'avec P3D ?

Il y-a-t-il une chance que le modèle de vol de MFS pour 2024 soit corrigé ? J'imagine que ça casserait la compatibilité avec les avions existants...

Filoux · [↑]

C'est possible mais cela demande un investissement de la part des développeurs (se former au nouveau modèle, oser sauter dans l'inconnu en dehors du nid douillet de l'environnement de FS qui cadre pas mal les choses, et mettre en place l'infra qui injecte les x,y,z et vx, vy, vz vers MSFS) et une certaine prise de risque: cela revient à tout mettre par terre, reconstruire de 0....

Peu nombreux ceux qui osent sauter le pas: à part A2A je n'en connais pas.

Pour ma part, je m'éclate avec Flightgear qui repose sur JSBSIM. On peut vraiment tout faire, y coder implémenter des fonctions mathématiques via la structure xml. Avec lui on peut même coder une aile différente pour chaque bec de bord d'attaque et moduler cette aile avec les volets de bords de fuite. Cela permet par ex de simuler la config d'une aile atypique en situation de panne hydrau. flaps full, no slats... Gare aux incidences un poil trop grande !

Boufogre · [↑]

Ragg Sor a écrit :

Hello à tous, j'ai une petite question, inspirée par la lecture de vos retours, de vos expertises (en présumant que vous ne vous trompez pas)

Vu que vous êtes en train de rentrer dans des détails assez fous (pour les béotiens comme moi) pour corriger le comportement du Fenix quand il est en N-1 entre 17 et 19°C sous un angle de 22,87° avec en effet l'âge du capitaine pair et avec une humidité supérieure à 17% (pour la team premier degré, relax, vous me comprenez je pense), et vu que vu la qualité du bestiaux je pense quand même que chez Fenix ou Asobo ils sont pas complètement manchots....

La physique étant ce qu'elle est, les formules mathématiques pour expliquer ceci ou cela, pour le simuler, et la complexité de tout ça étant de faire fonctionner tout ça en même temps... Je me demande si en mettant "les bonnes formules" aux bons endroits absolument partout, que la "faute" soit chez MSFS ou chez Fenix, ou chez les deux, on n'aurait pas un comportement incohérent voire très très mauvais ?
Parce que justement, certaines interactions entre différents phénomènes physiques n'ayant jamais été modélisées, il manque un truc quelque part, parce que c'est de la simulation et que donc en l'état actuel de l'art, on n'est toujours pas au perfect de l'imitation du réel...
Et que du coup, fasse à ce constat, les développeurs doivent "bricoler" des formules pourtant correctes, les rendant incorrectes, parce qu'en testant, et bien l'avion se comporte globalement de manière plus cohérente avec la fausse formule, car ça palie je ne sais quel défaut que personne n'est pour le moment en mesure de comprendre/trouver/modéliser ?

Et que du coup, si on recentre la barre en revenant aux "bonnes" formules, et bien ça fausse le tout? Rentrer dans le détail d'une formule isolée avec des courbes et des calculs, sur papier c'est bien, mais si ça se trouve, une fois que c'est mis en musique au milieu de tout le reste... C'est là que le bas blesse.

Une hypothèse comme ça, sachant que dans plein d'autres domaines, c'est ce qu'il se passe, on a la théorie, on arrive au pratique avec un résultat pas exactement pareil parce que l'état de l'art est incomplet, et on bricole un peu, dans des marges acceptables, pour arriver au résultat désiré ?

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...

niokilt · [↑]

Ce qui fait peur, quand on vous lit, c'est d'en tirer la conclusion probable que ce sera pareil pour FS2024..qui sort dans deux mois!

Dernière modification par niokilt (12-09-2024 09:52:26)

Filoux · [↑]

Laissons sa chance à MSFS 2024. Nous verrons bien. Par contre si vous voyez dans les communications d’Asobo des avancées en matière de CFD, ou de wind tunnel virtuel, vous pouvez vous dire que c’est du marketing pour gogo. La modélisation des écoulements par ordinateur demande énormément de ressources et un maillage extrêmement fin autour de l’avion. Dites vous bien que le calcul des forces sur un cessna avec cette methode pour un simple point de vol mettrait facilement une bonne journée. On parlerait de FPD et non FPS. Asobo a tenté la CFD pour mettre en valeur Azure avec des modeles hyper simplifiés d’avion (on parle de cubes presque..). En vol ca donnait des instabilités énormes, et rien de probant en matière de perf… personne ne l’utilise aujourd’hui. Ce chapitre m’a ouvert les yeux sur le coté trop marketing de msfs.

niokilt · [↑]

Une petite vidéo du problème qu'il y a sur le fenix avec l'ENG FAIL que j'ai décrit plus haut, faite par un youtubeur qui lui découvre le truc!

le TO commence à 3 min

Dernière modification par niokilt (13-09-2024 09:26:12)

Ragg Sor · [↑]

Il me semblait bien que Fenix avait un model de vol en propre et n'utilisait pas celui de MSFS?

Ragg Sor · [↑]

Filoux a écrit :

La modélisation des écoulements par ordinateur demande énormément de ressources et un maillage extrêmement fin autour de l’avion. Dites vous bien que le calcul des forces sur un cessna avec cette methode pour un simple point de vol mettrait facilement une bonne journée.

T'as une source de ça stp? A froid comme ça, ça parait... Difficile à croire !

Boufogre a écrit :

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...

Merci pour ton explication. En revanche, je ne comprends pas bien. Tu veux dire que leur table avait le même fuel flow quelle que soit la densité ?(puisque la densité change en fonction de l'altitude) Une table avec la même valeur à tous les étages?
Et du coup, si le SDK décrit un truc faux, comment fait on pour connaitre ce qui est fait en vrai ? (ici, la table en question)

Dernière modification par Ragg Sor (13-09-2024 18:33:34)

Boufogre · [↑]

Non, la table était bien mais incomplète : à densité égale, mais à nombre de Mach différent, le fuel flow change et cet effet est impossible à reproduire avec la table en question.

Pourquoi mettre cette table au lieu d'implémenter la formule correcte? Ça n'a aucun sens pour moi...

Ragg Sor · [↑]

Ha ok je comprends mieux merci

Hargn · [↑]

Hello, je viens d'installer et tester l'A320 pour la première fois hier, et ouille, niveau performances il est bien plus lourd que le FBW.
J'ai eu une sorte de blocage lors du vol LFPG-EDDF de test : toutes les interfaces ont figées.
Du coup je me demande si il y a un taux d'images (FPS) minimum recommandé pour voler.

Je peux jouer sur le trafic AIG, mais niveau décors/scène, je veux/peux plus baisser dans les paramètres.

Avance · [↑]

New Fenix update A32X 2.2.0.351

**Fenix A32X 2.2.0.351 changelog:**

**Known Issues**

- Pitch oscillation issues still being actively worked on, not yet resolved (a fix is currently in dev)

**Avionics and Systems**

- Added support for physical ACARS printers including separate auto-print options for ACARS and TELEX
- Added support for SayIntentions ACARS
- Added Lvar for PCA
- Added ambient light sensors to DU/DCDU/ISIS/MCDU
- Added TELEX message sender to AOC MSG DISPLAY page
- Modified how RETARD is triggered internally
- Improved sensitivity of centreline bumps
- Improved logging around Hoppie
- Improved A319 VNAV performance
- Improved logging around Fenix hooking/startup
- Fixed numeric-only aircraft registrations not showing on the placard
- Fixed 8.33 KHz frequencies like 121.555 not being selectable
- Fixed placement of “H” in chrono display
- Fixed typo in LGCIU failures
- Fixed various potential crashes throughout the systems
- Fixed payload being wiped when aircraft weights are reset
- Fixed “DON’T SINK” GPWS callout not being played
- Fixed bug when descent segment initial altitude is above the ceiling
- Fixed incorrect FROM in Hoppie TELEX messages
- Fixed CHR/stopwatch not resetting to a negative time value
- Fixed aircraft payload stations being reset
- Fixed some ACARS printers not showing

**Art and Sound**

- Added hubcaps to A320 model
- Added A319 high density configuration
- Reduced VRAM usage in interior
- General sound fixes & improvements
- RETARD looping infinitely should be solved, if it is, David is going on vacation
- BATT whine volume decreased
- Gear extension whine improved
- Cabin packs/wind vol adjustments
- Fixed several CFM sound regressions
- Fixed A319 and A302 slat marking missing
- Fixed logic for RETARD using max loop length
- Fixed tooltips not showing on A319 & A321

**EFB**

- Massively improved take-off performance code
- Fixed DLH OFPs missing weather information
- Improved settings page design
- Fixed brightness not persisting between sessions
- Fixed numeric input entry
- Fixed incorrect number of rows on A319 seat map
- Fixed “adjust planned weights” being incorrect in lbs
- Fixed EFB brightness not being saved

**Flight and Engine Models**

- Minor adjustment to flaps 3 & full drag on A319
- Gently adjusted differential braking so the airplane is not so wiggly during toe brake application.

ydelta · [↑]

Je reviens sur les discussions concernant le modèle de vol de MSFS car j'ai pu regarder un peu plus en détail le SDK et ce qui est calculé par les différents debugs du mode developper.

Ma conclusion est que la façon dont tout cela est calculé n'est pas forcément fausse mais ce qui est clair est que cela n'aide pas à comparer les polaires théoriques classiques avec celles du simulateur et donc la mise au point d'un avion doit s'accompagner d'une phase de tests assez fastidieuse qui doit permettre d'affiner les paramètres avec tous de scalaires idoines.

Déjà pour comprendre de quoi on parle il faut savoir en effet que MSFS utilise un modèle de vol dit « moderne » mais qui assure une certaine retro-compatibilité avec le modèle « legacy » de FSX afin justement que les avions développés pour FSX puissent être portés sur la nouvelle plate-forme.
La grande différence du modèle de vol moderne est qu'il utilise un process de soufflerie aérodynamique virtuelle basée sur la dynamique des fluides (CFD) qui simule l'écoulement des flux d'air sur les surfaces de l'avion en temps réel, ce qui permet notamment de déterminer des forces qui s'appliquent comme la portance ou la traînée qui sont évidemment fondamentales pour simuler le comportement d'un avion en vol.

Prenons l’exemple de l’A320 Asobo (mais c’est aussi valable pour n’importe quel avion). On peut voir dans la fenêtre de debug en haut qu’ils commencent par calculer la force de portance (lift) et celle de traînée (drag) en pounds (lbs). Ici on voit que le drag est de 6922 lbs et le lift de 135084 lbs. Ensuite ils déterminent les coefficients de drag (CD) et de lift (CL) associés à ces forces via la formule (force / pression dynamique x surface alaire) dont les valeurs fournies dans le debug (pression dynamique moyenne = 178.09 PSF et surface alaire = 1313.1 sqft)
Si on fait le calcul on trouve un CD de 0.02960 et un CL de 0.57760 qui est d’ailleurs ce qui est indiqué dans le debug pour les valeurs moyennes. On voit aussi en bas de la fenêtre qu’ils distribuent CL et CD sur les différentes parties de l’avion (ailes, fuselage, dérive et empennage)

Une fois qu’on a CD et CL ils vont déterminer le Cd0 de manière dynamique en calculant le coefficient de traînée induite (Cdi) via la formule « améliorée » CD = Cd0 + k * (CL – CL0)^2 en utilisant le CD et le CL calculés précédemment. k est le calcul standard qu’on peut déterminer facilement via la formule 1 / (Pi * AR * e) avec AR = aspect ratio et e le coefficient d’Oswald cher à notre ami Bee Gee

Si on se trouve en vol stabilisé à vitesse constante et température proche des conditions standard le Cd0 calculé doit être proche de celui théorique fourni dans le ficher flight_model.cfg sous drag_coef_zero_lift. Ici on voit qu'il vaut en moyenne 0.02038 c'est à dire assez proche du théorique qui vaut ici de 0.02370. La différence provient des conditions de tabulations du Cd0 théorique qui se détermine normalement dans des conditions de vol où la traînée parasite est la plus faible (i.e. typiquement en vitesse de croisière pour un avion de ligne).

La décomposition du calcul de CD est ensuite fourni dans le debug pour les valeurs min, max et moyenne calculées en soufflerie virtuelle.

Ensuite, et c’est là que cela avait posé quelques questions à Boufogre et Filoux, on a un calcul de décomposition du Cd0 qui part du paramètre drag_coef_zero_lift qui correspond au Cd0 dans le fichier flight_model.cfg multiplié par un scalaire qui permet de régler plus finement le modèle de vol en augmentant ou diminuant ce paramètre auquel s’ajoutent des coefficients de traînée des trains, des volets et des spoilers aussi que le mystérieux « other_drag » qui fait l'objet d'une décomposition supplémentaire dans le débug.

Ce qui prêtait à confusion c'était que ce other_drag pouvait prendre des valeurs négatives alors qu'en réalité c'est impossible car une traînée négative correspond à une poussée ce qui n'est physiquement pas possible (il n'y a que les moteurs qui génèrent de la poussée)

Mon observation sur ce point est que ce paramètre change en fonction de la position des surfaces de vol donc je dirais qu'il ne faut pas trop y faire attention pour calculer une polaire car en vol stable et lisse ce paramètre doit rester très proche de 0 comme ici dans l'exemple.
Je pense que nos amis d'Asobo l'utilisent comme variable d'ajustement pour fitter leur modèle quand on fait varier les surfaces de vol qui engendre des valeurs négatives parfois mais bon pour moi cela n'a pas vraiment d'importance car ce qui compte au délà de grapher des polaire théroriques c'est de comparer le comportement de l'avion simulé par rapport aux valeurs attendues et je me rappelle que Filoux avait indiqué que le Fenix (pour en revenir au sujet de ce fil) avait une courbe de descente proche des courbes réelles donc le comportement du modèle de vol était assez fidèle.

Maintenant ce qui reste un peu flou c'est la partie qui réconcilie le calcul avec le niveau target théorique du CD et du Cd0 et notamment cfg_cdi qui a l'air de correspondre au coefficient de traînée induite qui serait extrapolé du fichier flight_model.cfg, à moins qu'il soit calculé à partir des données fournies dans le target_performance.cfg (qui n'est pas disponible pour tous les add-ons). Egalement le achieved_Cd0 qui est différent du Cd0 théorique et aussi de celui calculé plus haut mais il semblerait qu'il est calculé pour un AOA spécifique (ici visiblement 1.7 degrés) donc c'est peut-être la raison.

Voilà en tout cas je souhaite bien du courage aux devs d'avions (je comprends que notre ami Boufogre s'occupe du modèle du 747i Salty) car c'est pas simple de s'y retrouver
C'est aussi pour cette raison probablement que le coefficient d'Oswald a été paramétré à 0.43 pour le Fenix au lieu du 0.78 théorique pour l'A320 avec un induced_drag_scalar > 1 pour fitter au mieux le modèle de vol réel mais du coup qui rend l'aile moins efficace aux basses vitesses comme la situation décollage N-1 testée dans les posts précédents de ce fil de discussion.

Dernière modification par ydelta (16-09-2024 19:49:48)

Boufogre · [↑]

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...

ydelta · [↑]

Boufogre a écrit :

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

Alors effectivement sans accès au code source cela est difficile de le savoir avec certitude, maintenant ce qu'on peut comprendre des différentes informations glanées ci et là c'est qu'ils utilisent une approche hybride qui combine un modèle de vol basé sur des coefficients aérodynamiques classiques avec leur modèle de vol physique "amélioré" qui fait usage de la CFD.

De manière plus concrète on peut imaginer une synthèse entre :

1. les paramètres et coefficients de traînée tabulés dans le fichier flight_model.cfg pour le zero lift, les Mach correspondants et les différentes sources de trainée (train, volets, spoilers)

2. une modélisation du flux d'air basée sur la CFD pour fournir des ajustements plus précis de la traînée dans des conditions spécifiques, en particulier lors d'interactions complexes de flux d'air (séparation des flux afin de les re-circuler sur les ailes et d'autres surfaces, variations de pression dynamiques pour simuler les flux turbulents, prise en compte des conditions météo)

Après tu as dû voir aussi que dans le SDK ils fournissent une feuille Excel qui détaille un certain nombre de calculs qui sont utilisés pour déterminer les paramètres du fichier flight_model.cfg.
Il y a par exemple de calcul du Cd0 à partir du Cl0, de la densité de l'air, de la masse, de la surface alaire, de la puissance max des moteurs et de la vitesse en vol stabilisé et configuration lisse.

J'ai testé le vol en croisière à vitesse green dot, voici le debug. J'arrive à recalculer le Cd0 affiché avec les paramètres suivants de la feuille XL. Je ne sais pas si c'est ce qu'ils font en temps réel comme calcul mais doivent certainement faire quelque chose qui s'en rapproche.
Pour ce qui est de other_drag, je n'ai pas vu de différence significative avec le debug précédent à plus faible altitude, il reste dans les mêmes ordres de grandeur j'ai l'impression et c'est toujours à cause de side_slip_&_control_surfaces dont on en sait pas trop à quoi cela correspond. Pour info j'ai détéré un post de 2022 sur le Forum dev MSFS qui demandait à quoi correspondait ce drag et j'ai reposté aujourd'hui en demandant si on avait eu des réponses depuis car il n'y avait pas eu d'autres messages...

Dernière modification par ydelta (17-09-2024 10:50:18)

niokilt · [↑]

ydelta a écrit :

Filoux a écrit :
Le K est bien de 0.04365 avec un scalaire de 1 et un Oswald de 0.78.
Résultat des courses: on voit que la courbe de MSFS ne colle pas du tout avec le calcul du SDK...
Donc attention, je pense que les devs ont constaté comme moi ce décalage et on adapté les coeffs pour fitter au mieux.
En modifiant les valeurs, vous risquer de pourrir d'autres parties du MDV.
Intéressant donc ce qu'on doit en conclure c'est que les valeurs du MDV par défaut du Fenix sont un compromis pour essayer de mieux fitter disons 95% du modèle de vol calculé par MSFS mais que pour certaines situations (i.e. par ex N-1 MTOW comme pour notre test) cela ne colle pas et il faut alors modifier les paramètres ?
En gros il faudrait avoir au moins deux fichiers flight_model, un pour les situations de vol 'standard' et un pour les situations marginale/extrêmes :)
Je pense que pour les pilotes réels comme Flomartin ou Jpette cela faudrait le coup de faire un petit script en BAT pour lancer MSFS avec le modèle de vol ad hoc en fonction du type d'entrainement voulu.
D'ailleurs pour ceux qui veulent s'entraîner sérieusement à différentes phases de vol sans passer des heures à tout configurer, je recommande fortement FSI Panels qui est très bien fichu et supporte le 320 Fenix, plus d'info et tarifs -> https://www.fsipanel.com/

Hello, j'ai réinstallé FSI panel que je possédais en version standard. j'ai regardé attentivement leurs différentes MAJ payantes de leur soft ainsi que quelques vidéos, et je me demande: tu disais Ydelta que c'était rapide à configurer. Est ce la fonction snapshot dont tu parles?
Parce que pour avoir vu une vidéo tutoriel de cette fonction, il faut pour chaque nouveau scenario, configurer le MCDU de FSI panel et sauvegarder le scenario. est ce que tu peux confirmer que c'est bien de ça dont tu parlais dans ton post? ALors ce n'est pas trop le temps que ça prend de paramétrer le cdu, mais je trouve cela laborieux.
Ensuite, moi quand je clique sur snapshot avec le fenix par exemple une fenêtre de fsi s'ouvre me demandant d'upgrader en version advanced. donc il faut repasser à la caisse.. seulement le tableau montrant les différences entre les versions indique dans l'onglet note que snapshot est uniquement dispo pour PMDG et maddog... donc peut être que le tableau n'est pas à jour mais je n'ai pas envie de payer pour rien. En plus l'upgrade coute 14$ je trouve ça cher..mais bon..
Merci à toi

Boufogre · [↑]

ydelta a écrit :

Alors effectivement sans accès au code source cela est difficile de le savoir avec certitude, maintenant ce qu'on peut comprendre des différentes informations glanées ci et là c'est qu'ils utilisent une approche hybride qui combine un modèle de vol basé sur des coefficients aérodynamiques classiques avec leur modèle de vol physique "amélioré" qui fait usage de la CFD.

De manière plus concrète on peut imaginer une synthèse entre :

1. les paramètres et coefficients de traînée tabulés dans le fichier flight_model.cfg pour le zero lift, les Mach correspondants et les différentes sources de trainée (train, volets, spoilers)

2. une modélisation du flux d'air basée sur la CFD pour fournir des ajustements plus précis de la traînée dans des conditions spécifiques, en particulier lors d'interactions complexes de flux d'air (séparation des flux afin de les re-circuler sur les ailes et d'autres surfaces, variations de pression dynamiques pour simuler les flux turbulents, prise en compte des conditions météo)
Après tu as dû voir aussi que dans le SDK ils fournissent une feuille Excel qui détaille un certain nombre de calculs qui sont utilisés pour déterminer les paramètres du fichier flight_model.cfg.
Il y a par exemple de calcul du Cd0 à partir du Cl0, de la densité de l'air, de la masse, de la surface alaire, de la puissance max des moteurs et de la vitesse en vol stabilisé et configuration lisse.

J'ai testé le vol en croisière à vitesse green dot, voici le debug. J'arrive à recalculer le Cd0 affiché avec les paramètres suivants de la feuille XL. Je ne sais pas si c'est ce qu'ils font en temps réel comme calcul mais doivent certainement faire quelque chose qui s'en rapproche.
Pour ce qui est de other_drag, je n'ai pas vu de différence significative avec le debug précédent à plus faible altitude, il reste dans les mêmes ordres de grandeur j'ai l'impression et c'est toujours à cause de side_slip_&_control_surfaces dont on en sait pas trop à quoi cela correspond. Pour info j'ai détéré un post de 2022 sur le Forum dev MSFS qui demandait à quoi correspondait ce drag et j'ai reposté aujourd'hui en demandant si on avait eu des réponses depuis car il n'y avait pas eu d'autres messages...

Ce tableur sert normalement à trouver quels paramètres mettre dans le flight_model.cfg.

Tu retombes en effet sur tes pattes, mais si tu regarde bien, en suivant la logique de ce fichier, le designer aurait dû mettre pour le paramètre drag_coef_zero_lift la valeur 0.0197, or il a mis la valeur 0.02370 (cfg_cd0 dans le debug), et là ça ne colle plus.

Filoux · [↑]

Ragg Sor a écrit :

Filoux a écrit :
La modélisation des écoulements par ordinateur demande énormément de ressources et un maillage extrêmement fin autour de l’avion. Dites vous bien que le calcul des forces sur un cessna avec cette methode pour un simple point de vol mettrait facilement une bonne journée.

T'as une source de ça stp? A froid comme ça, ça parait... Difficile à croire !

Boufogre a écrit :
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...

Merci pour ton explication. En revanche, je ne comprends pas bien. Tu veux dire que leur table avait le même fuel flow quelle que soit la densité ?(puisque la densité change en fonction de l'altitude) Une table avec la même valeur à tous les étages?
Et du coup, si le SDK décrit un truc faux, comment fait on pour connaitre ce qui est fait en vrai ? (ici, la table en question)

Sur les temps de calcul en CFD, mon expérience vécue est de plusieurs heures pour un modèle 3d avec un meshing fin de la veine autours. Bien entendu je ne demande pas de me croire sur parole donc une petite recherche sur google suffit:

https://synergenog.com/helpie_faq/how-long-does-a-cfd-simulation-take/

Dernière modification par Filoux (17-09-2024 18:31:37)

#301 [↑][↓] 10-09-2024 20:33:34

Re : [MSFS]Fenix A320 V2

#302 [↑][↓] 10-09-2024 21:29:40

Re : [MSFS]Fenix A320 V2

#303 [↑][↓] 11-09-2024 10:01:06

Re : [MSFS]Fenix A320 V2

#304 [↑][↓] 11-09-2024 12:08:51

Re : [MSFS]Fenix A320 V2

#305 [↑][↓] 11-09-2024 12:58:52

Re : [MSFS]Fenix A320 V2

#306 [↑][↓] 11-09-2024 17:13:15

Re : [MSFS]Fenix A320 V2

#307 [↑][↓] 11-09-2024 17:41:55

Re : [MSFS]Fenix A320 V2

#308 [↑][↓] 11-09-2024 17:48:23

Re : [MSFS]Fenix A320 V2

#309 [↑][↓] 11-09-2024 21:15:26

Re : [MSFS]Fenix A320 V2

#310 [↑][↓] 12-09-2024 08:15:52

Re : [MSFS]Fenix A320 V2

#311 [↑][↓] 12-09-2024 09:49:21

Re : [MSFS]Fenix A320 V2

#312 [↑][↓] 12-09-2024 22:25:17

Re : [MSFS]Fenix A320 V2

#313 [↑][↓] 13-09-2024 09:25:09

Re : [MSFS]Fenix A320 V2

#314 [↑][↓] 13-09-2024 17:37:24

Re : [MSFS]Fenix A320 V2

#315 [↑][↓] 13-09-2024 18:28:18

Re : [MSFS]Fenix A320 V2

#316 [↑][↓] 13-09-2024 20:12:14

Re : [MSFS]Fenix A320 V2

#317 [↑][↓] 13-09-2024 22:32:38

Re : [MSFS]Fenix A320 V2

#318 [↑][↓] 16-09-2024 10:50:02

Re : [MSFS]Fenix A320 V2

#319 [↑][↓] 16-09-2024 19:09:00

Re : [MSFS]Fenix A320 V2

#320 [↑][↓] 16-09-2024 19:15:06

Re : [MSFS]Fenix A320 V2

#321 [↑][↓] 16-09-2024 20:13:05

Re : [MSFS]Fenix A320 V2

#322 [↑][↓] 17-09-2024 00:21:43

Re : [MSFS]Fenix A320 V2

#323 [↑][↓] 17-09-2024 12:26:00

Re : [MSFS]Fenix A320 V2

#324 [↑][↓] 17-09-2024 13:38:24

Re : [MSFS]Fenix A320 V2

#325 [↑][↓] 17-09-2024 18:30:26

Re : [MSFS]Fenix A320 V2

Pied de page des forums