Varför är flygsimulatorer dåliga för att förutsäga drag- och lyftvärden vid höga angreppsvinklar? (den olinjära flödesregimen)

10

X-Plane är byggt på något som kallas bladelementteori. Från min förståelse står det att flygplanets prestanda kan hittas om prestandan för 2D-tvärsnitt beräknas och integreras i realtid. Laminar Research (tillverkaren av X-Plane) använder det som försäljningsplats för X-Plane och säger att det kan användas för att hjälpa flygplandesigners att testa sina konstruktioner under flygning på datorn innan de bygger prototyper. Men som kommentatorer på detta forum har skrivit tidigare (Peter Kampf) är de flesta flygsimulatorer dåliga för att förutsäga flygplanets prestanda vid höga angreppsvinklar utan att använda en tabell med kraftkoefficienter som genereras genom vindtunneldata eller detaljerad CFD.

Min fråga är vad i flödesfysiken driver detta? Vilken del av fysiken modelleras felaktigt för att ge skräppost vid höga angreppsfunktioner?

    
uppsättning user11377 06.10.2015 02:06

4 svar

9

Laminärflödet är enkelt . Även om det finns en komplett uppsättning differentialekvationer som beskriver något fluidflöde finns det en mängd förenklingar och antaganden som du kan använda på laminärt flöde. Det betyder att X-Plane inte behöver modellera all luft runt vingen, men kan göra beräkningarna baserade på vingeprofil och lokala hastigheter. Allt är relativt linjärt, så du kan bara ändra vissa variabler och använda förutbestämda parametrar. Dessutom är det helt tidsinvariant i steady state. Du kan nu enkelt lösa ekvationerna, integrera den beräknade tryckprofilen längs vingen och gjort!

För turbulent flöde håller inget av det. Det nuvarande sättet att simulera turbulent flöde är att göra en analys eller liknande för en Finite Element -analys (t.ex. FDM ). I grund och botten måste du överväga all luften i en stor volym runt vingen, dela upp den i ett litet rutnät och simulera det. För en bra beräkning tar detta i storleksordningen sekunder till minuter för ett enda 2D-tvärsnitt på min ganska anständiga bärbara dator. Och då försummar vi 3D-påverkan. Vidare förändras turbulent flöde w.r.t. tid. Öppna till exempel ditt bilfönster på motorvägen - du kommer att höra vindbrullen och pulsera. Det betyder att du måste få ditt tidigare tryck- och hastighetsfält och använda det som utgångspunkt för din nästa FEM / FDM-analys. Slutligen är turbulent flöde extremt svårt att förutsäga korrekt, även med ovanstående metoder: En lite hårdare yta, en liten bult eller en liten vindgust kan fördröja flödesskillnaden för några inches, vilket helt och hållet ogiltigförklarar dina resultat. Kanske denna YouTube-video (notera: det här är inte simulerat i realtid! ) kan ge lite ljus över den enorma komplexiteten och tidsberoendet för turbulent flöde - och kom ihåg att din horisontella stabilisator ser störd luft i stallförhållanden, vilket gör det nödvändigt att simulera hela flödesfältet runt flygplanet för en korrekt simulering, inte bara vingsektionerna.

Naturligtvis har X-planet en framerate mätt i bildrutor per sekund, inte ramar per timme. Det innebär att de använder en massa antaganden för att beräkna vingehissen. Jag gissar att de bara har några värden för placeringen av flödesseparation och turbulent tryck för vissa fasta hastigheter och vinklar, och interpolerar till de verkliga värdena. Min gissning är att de också har några parametrar som inte faktiskt beräknas, men är valda så att vissa väldigt grundläggande manövrar är möjliga som spin recovery, oavsett om dessa värden motsvarar några fysiska fenomen - det är ju ett spel.

    
svaret ges 06.10.2015 12:28
3

Eftersom det verkliga luftflödet inte är 2D laminärt.

Inte säker på hur långt vi är med 3D turbulent flöde CFD vid lägre attackvinklar. Men med höga angreppsvinklar skiljer sig luftflödet från strömkroppen och skapar ett vild och slumpmässigt mönster av flödesfluktuationer - inte den bästa kandidaten för CFD.

Nivå D-fullflygsimulatorer måste matcha en uppsättning data som mäts på ett verkligt flygplan. Denna uppsättning data är runt rimliga flygförhållanden, som vanligtvis förekommer vid flygintäkterna, och inkluderar de flesta nödsituationer som piloter är utbildade i.

Pitch AoA mäts mellan ca -2º för att stoppa igång, ca 25º. och +/- 15º sideslip, men inte i kombinationer av extremt AoA och sideslip. Regionen som mäts under flygprov ser ut som den gröna finns på bilden nedan, vilka är flygstaterna där nivå D-simulatorer måste vara mycket nära matchade flygdata:

De blå och gula rutorna är interpoleringar och extrapoleringar av tabelluppslagningsdata som används för Acceptionsområdet. Detta är tillräckligt för att träna in i stall, men inte tillräckligt för att träna återhämtning från en fullt utvecklad stall som vad som hände med AF 447. FAA kommer att införa ett krav att piloter tränar återhämtning från en fullt utvecklad stall och Airbus och Boeing arbetar om uppdatering av sina datapaket.

Vissa uppgifter om kraschade flygplansflygare och vindtunneldata har använts för att modellera stallbeteende hos olika flygplattyper (lågvinge, T-svans osv.) och de första simulatorn är redan i drift som kan träna detta. Alaska Airlines har en.

    
svaret ges 26.04.2017 06:45
0

Jag kan inte svara på vilken CFD-modell (eller strategi / mix därav) används av någon av flygsimulatorn.

Jag kan säga att CFD, i allmänhet, är mer begränsad av tillgängliga resurser (FLOPS och tid) än vad det handlar om precision. Åtminstone är detta fallet för en mängd olika situationer där flygsimuleringen sker mest.

Realtidsflygsimulering (idag) måste använda stenografi 'parametreringar' i simuleringsnätet, för att lösa modellstyrkor vid FPS i användarupplevelsen. Om COU (och potentiellt GPU) kan utföra mer ops, kan simuleringsnätet använda lådor som är mindre - sålunda högre upplösning och mer exakt.

Högre rumsliga simuleringsnät, tillsammans med högre temporala upplösningsnät, kan bättre fånga små flödesfel. Dessa leder till förändringar i flödestopologin, kompressionsvågor, gränsvärdesavskiljningar och andra mer komplexa nonlineariteter.

    
svaret ges 06.10.2015 05:41
0

Jag är ledsen, jag kan inte svara på fysikdelen. Det kan vara en bra fråga om Physics StackExchange .

I programmeringssynpunkt (SuperUser?):

  • Beräkningar av flytande punkter är bland de mest CPU-intensiva.
  • Precisionsfrågor när man pratar om fysikbeteende. Utan tillräcklig precision kan vissa parametrar hoppa från ett värde till ett överdrivet, till och med motsatt värde (stackoverflöde), även om det är nästa tillgängliga värde som kan lagras i bitar. Allt en dator kan göra är approximationer.
  • Cykeluppdatering / uppdateringscykel eller intervallvaraktighet mellan tillståndsändringar i fysikparametrar. 10 millisekunder kan se riktigt små och bra på att simulera fysikegenskaper. Ta dock med flygplanet i stallförhållanden och du inser att 10ms inte räcker för att noggrant lösa alla ytkomponenter effektivitet på en vanlig dator. Därför har du på vissa simulatorer, i synnerhet de gamla, oväntat luftfartygs beteende som brutala rullar / platser / yaws.
  • Race villkor. Detta är en oro för parallella uppgifter som görs av datorn. Enkelt uttryckt är en uppgift att beräkna vektorkrafter som tillämpas på flygplanet. En annan parallell uppgift är användar- eller autopilotingångar. En annan uppgift är att skapa nya luftflödesförhållanden, som vind och turbulenser. De är inte synkroniserade. Ju mer uppgifterna, de andra asynkrona beräkningarna sker.
  • En dator gör precis vad det har blivit lärt att göra. Flygplanet kan bryta om värdet på en parameter går till en viss gräns, och en brutal överreaktion induceras av en felberäknad parameter (på grund av uppdateringscykeln ovan eller föråldrade parametrar på grund av async multi-uppgifterna). Vissa dämpningsbackbacks-kontroller kan vara läggs till i koden (som på datordrivna pilotsingångar), men det lägger också till fler beräkningar att utföra på användardatorn där simulatorn är installerad.
  • Slumpmässig uppdatering. För att skapa turbulenser måste du till exempel skapa dynamiska slumpmässiga parametrar vars gränser ändras beroende på väderleksförhållanden, höjd, geografiska platser etc. Detta tillägger de totala beräkningarna som ska utföras.
  • Simulatorn måste förresten göra grafiska data på skärmen och hantera tusentals objekt med miljontals parametrar. Det är också därför, i motsats till X-Plane of FSX / P3D, inte riktiga professionella simulatorer bryr sig mycket om scenerobjekt (trafik) och annat ögonljus som molnens vackerhet eller solbländning. Eftersom fysikberäkningar prioriteras.

Det är inte så att datan är skadad eller felberäknad. De är 1) approximationer som resultat av mycket förenklade formler eller uppslagstabeller / matriser för att påskynda beräkningstiden och 2) uppdateras inte alltid i det ögonblick som de är mest nödvändiga (höga AOA) på grund av överdriven uppgift att utföra för att uppdatera dem . Att lägga till en parameter (som ett extra vingehäfte ovanför vingen) och beräkningar som ska utföras vid varje uppdatering kan öka linjärt eller exponetiellt. Fysikmodellen är inte inkorrekt, men den är heller inte den mest exakta.

I slutändan kan man komma nära den bästa möjliga approximationen, men på bekostnad av beräkningstiden. Vi hör ofta att en dator tog x veckor för att beräkna y trillions decimaler av Pi eller z dagar för att visa en exakt översikt över vår galax som kolliderar med M31 Andromeda. Att komma dit är möjligt, men ännu inte genom masspubliceringssimulatorer som X-Plane, FSX eller P3D. Vanliga datorer är inte kraftfulla, snabba och exakta nog, för att reproducera realtids fysikbeteenden som kompliceras som aerodynamik eller gravitation.

    
svaret ges 06.10.2015 12:21