Auftriebsbeiwerte für B777 in Flugsimulatoren?

[Schorsch]

Dass JavaScript nun nix mit Java zu tun hat, weißt Du aber?

Nie von gehört. Aber jetzt habe ich mal Wikipedia gefragt.
Wie auch immer, die meisten Sprachen können ja heute irgendwie allles.

Glaubt mir auch anfangs keiner, dass das Bild am Ende Matlab ist.

 

[cool]

Das "Springen" kommt vermutlich von einem immer noch zu großen Zeitinkrement (wie ist das eigentlich?), weil die IE11+Java Plattform anscheinend einen Multi-Core Prozessor auf die Geschwindigkeit eines 386SX Rechners runterprügelt.

Ist das Springen nicht generell ein numerisches Problem? Abhilfe kann man da idR schaffen, indem man die Schrittweite reduziert, oder die Konstanten/Koeffizienten anpasst. Ersteres wuerde ich immer machen, wenn die Simulation mal gut funktioniert hat, man kleine Dinge geaendert hat und die Sim dann rumzickt. Ich hab da bei manchen Dingen auch Stunden gesucht, dann (aus Verzweiflung) ein paar Iterationen auf Papier gerechnet (und da gings), und dann erst die Schrittweite reduziert.

Wenn ich das mit den Multi-Core-CPUs richtig verstanden habe, ist das ja auch ein generelles Problem. Matlab nutzt (erstmal) auch nur einen Kern, es geht ja um Iterative Aufgaben, sprich Schritt 1 muss erstmal abgearbeitet werden, dann Schritt 2 (weil er mit Daten aus 1 arbeitet) usw usw. Gleichzeitig Schritt 1/2/3/4 laufen lassen, geht ja nicht.
Man kann sowas schon aufdroesseln, aber das uebersteigt meine Faehigkeiten und dann auch nur Tasks, die eben nicht direkt aufeinander aufbauen. Ich hab selbes "Problem": Matlab nutzt nur einen Kern.
Man kann noch den Code bissi "straffen" und sauber programmieren (Matlab hat ja einen einfachen Syntax und erlaubt viele "Unachtsamkeiten") wie zb erstmal alle Variablen in Vollem Umfang deklarieren (wo es geht).

Ich waer wohl schon laenger auf scilab umgestiegen.

 

[LFeldTom]

Rechenleistung ist hier nicht das Problem (zumindest nicht bei dem was bisher gezeigt wurde). Das klappt auch auf jedem billigen Smartphone ohne Probleme, wenn man nicht künstliche Stolperfallen aufstellt. Multicore bringt nur etwas, wenn man hinreichend große Teilpakete hat, die man aufteilen kann.
Aus dem bisher gezeigten kann man noch jede Menge raus kitzeln - aber das ist wie gesagt nicht das Problem.

Bei OpenMP sagt man, dass man erst garnicht anfangen sollte Nebenläufigkeit ins Spiel zu bringen, wenn man nicht wenigstens 10E+5 Takte für die Teilaufgaben braucht. 10E+5 ist in unserem Beispiel sehr, sehr viel.

Vorsicht beim Thema Schrittweite. Die Schrittweite müsste schon ungewöhnlich groß sein, damit daraus resultierende Ungenauigkeiten bei einer simulierten B777 zu großen Sprüngen führt. Vor allem sollte man sich davor hüten seine Präzision nur mit immer kleineren Schrittweiten zu erkaufen. Ab einem gewissen Punkt überwiegen die Rundungsfehler (dt muss hierfür allerdings sehr klein sein). Da macht es mehr Sinn sich mit verbesserten numerischen Intergrationsverfahren zu beschäftigen. Ist genauer und kostet erheblich weniger Rechenleistung.

Ich würde immer noch schauen wollen, ob nicht die sich ändernde Basiswechselmatrix bei der Rotation (gamma) hier merkwürdige Dinge macht.

 

[cool]

Mit kleineren Schrittweiten kann man ja erstmal dafuer sorgen, dass der Wert auch korrekt gegen den Wert des Integrals konvergiert und nicht ausbuechst. Die Richtigkeit des Ergebnisses im Detail ist dann erst der Folgeschritt.

Wie gesagt, meine Erfahrung: bevor ich Stunden in Codesuche und umstricken verballer, setze ich erstmal die Schrittweite runter und schau mal was bei rum kommt. Zumindest bei Simulationen die irgendwie innerhalb weniger Minuten berechnet werden. Bestimmt nicht die sauberste Loesung, geht aber.

 

[LFeldTom]

Das war kein Plädoyer gegen eine kleinere Schrittweite. Man kann auch den Verlauf für verschiedene Schrittweiten auch übereinander plotten (bezogen auf eine feste Zeitachse). Dann sieht man ja, ob da deutliche Veränderungen passieren. Geht eigentlich sehr fix.

Bei dem beschriebenen Test scheint mir ein plötzliches Springen aber ungewöhnlich - zumindest bezogen auf dt. Egal ob nun 1ms oder 1Sek als Schrittweite. Da dürfte etwas anderes klemmen.

 

[Schorsch]

Eine Schrittweite unter 0.01 Sekunden muss man nicht versuchen.
Wie gesagt, mit 0.05 Sekunden (entsprechend 20Hz) ist man eigentlich gut bedient, bei einer reinen Performance-Simulation sind 0.1..0.2 Sekunden auch OK. Ich habe Trajektorien wie hier beschrieben mit .05s berechnet, da nebst dem Flugmodell eine Reihe von Reglern dabei waren, und die reagieren sehr allergisch auf sich ändernde Schrittweite.

Bei 18° Gamma und den besagten 295t Gewicht geht die Geschwindigkeit sehr schnell in den Keller. Da in jedem Zeitschritt der Auftriebsbeiwert berechnet wird, wird dieser unterhalb einer gewissen Geschwindigkeit irrsinnig groß.

Beispiel: Meine "B777" "fliegt" mit nur noch 50kts. Bei 295t wäre in Bodennähe mein
CL = (mg)/QdynS = 17.3
Natürlich wäre das richtige Flugzeug schon Jahre vorher im Strömungsabriss gewesen. Da dies hier aber nicht modlliert ist, berechnet sich der Widerstand zu:
CD = CD0 + k * (CL-CLmin)^2 = 22
Natürlich ein bekloppter Wert. Aber der Computer tut wie ihm befohlen.
Unser Flugmodell hat nun ein Widerstand, der etwa 380t entspricht. Dazu kommen sin(18°)*G.
In meiner Überschlagsrechnung komme ich auf etwa 1.5g, welche das Flugzeug nach hinten ziehen.

Sehr spaßig: nähernd sich die Geschwindigkeit null an (angenommen 1kts), erreicht mein Wert 3300g.
Wird die Geschwindigkeit negativ entspannt es sich wieder etwas, das resultierende CL steigt wieder. Es würde sich ein stabiler Flugzustand herausbilden, in der das Flugzeug mit einer stabilen negativen Geschwindigkeit "fliegt".

So lieber Kinder, das war "Numerik 101" und was passiert, wenn ich einfache Modelle mit nicht dafür vorgesehenen Eingaben konfrontiere. Und da sagt einer, dem Schorsch sein Modell sei falsch ...

 

[Schorsch]

Wenn ich das mit den Multi-Core-CPUs richtig verstanden habe, ist das ja auch ein generelles Problem. Matlab nutzt (erstmal) auch nur einen Kern ...

"Multi-Threading" ist eine Sache, die meines Wissens nur bei recht ausgefallenen Programmen angeboten wird (FEM etwa). Meines Erachtens auch vollkommen unnötig, man muss halt etwas CPU-schonend programmieren. Der Vorteil des nur einen Kern nutzend: man kann parallel mehrere Instanzen am laufen haben.

 

[stefanpc81]

Einen Fehler habe ich gefunden:
p_hoehe = 0.0065 * pos_z;
habe ich nur als Startwert genommen und vergessen, in die "Intervall-Berechnung" einzupflegen. Leider besteht das Problem danach trotzdem noch: Wenn man das Programm mal laufen lässt, Link siehe unten, merkt man, dass mit der Höhe der Schub kleiner als der Widerstand wird, deshalb die negative Geschwindigkeitsänderung. Ich glaube, irgendwo muss man dem Programm noch sagen, dass bestimmte Minuswerte auf 0 gesetzt werden sollten (genau so wie ich es bei CL gemacht habe). Nur welche?

@LFeldTom

// spezifisch für deine Simulation
Fx = cos(gamma) * (FT [Schub in N] - FW) - sinus(gamma) * FG;
Fy = sin(gamma) * (FT [Schub in N] - FW) - cosinus(gamma) * FG;

// allgemein - unabhängig vom simulierten Objekt
A_x = Fx / masse;
A_y = Fy / masse;

V_x += A_x * dt;
V_y += A_y * dt;

pos_x += V_x * dt;
pos_Y += V_y * dt;

wollte ich umsetzen, hatte aber zur Folge, dass bei (gamma)=0 eine Höhenänderung stattgefunden hat.

const double temp_std = 288.15;

const double mag HTM/Javascript nicht. Es hat zur Folge, dass das Skript offenbar nicht ausgeführt wird, in meinem konkreten Fall bleibt die HTM-Seite leer bzw. hat nur die Hintergrundfarbe aus BGCOLOR in <BODY>.

@Schorsch

Herzlichen Glückwunsch: Du hast die Erdanziehungskraft entdeckt. Schon ne coole Sache mir zu sagen welcher meiner Formeln wohl falsch sind. Der Blinde erzählt dem Sehenden etwas von der Farbe.

Entschuldigung. Hätte ja sein können, dass du einen Denkfehler gemacht hast.

@all

Vielleicht hast du ja Lust deinen aktuellen Source Code mal komplett weiter zu geben. Mehr Augen sehen manchmal auch mehr...

Wer will, kann sich das Programm im Web ansehen oder beide Dateien herunterladen. Zu finden unter
http://www.stefanprobst1981.de/test.htm
http://www.stefanprobst1981.de/interpolation.js

 

[Schorsch]

Hier mal eine kleine Rechnung.


Der dafür notwendige Code:

m = [180 210 240 270 300];
H = 3000;
[rho,p,a,T]=atmos(H);
v_kts = 250;
Sref = 420;
v_kts = 150450;
gamma = 0:.1:25;
gamma_max = zeros(length(m),length(v_kts));
CD0 = 0.017;
ka = 0.075;
CLmin = 0.1;
THR0 = 83622.4;
lapse_spd = 0.5;
lapse_alt = sqrt(rho/1.225);

for k=1:length(m)
for i=1:length(v_kts)
IAS = v_kts(i) * sqrt(rho/1.225);
v_mps = v_kts(i) * 1.852/3.6;
CL(i) = (m(k)*10000)/(Sref * rho/2 * v_mps^2);
if CL(i)<=1.2 && IAS<=350
CD(i) = CD0 + ka*(CL(i) - CLmin)^2;
DRAG = CD(i) * (Sref * rho/2 * v_mps^2);
l_fac = lapse_alt * interp1([0 400],[1 lapse_spd],v_kts(i));
FX = (l_fac*THR0-.1*DRAG) - 1000*m(k)*sind(gamma);
[FXmin,i1] = min(abs(FX));
gamma_max(k,i) = gamma(i1);
elseif CL(i)>1.2 && IAS<350
% there we stall again ...
elseif IAS>350
% Never go above VMO!
end
end
end

Sind ein paar Matlab-eigene Befehle drin. Ich sag mal das Interpolieren aus einer Geraden bekommt man noch so hin.
Der Befehl "atmos" ist tatsächlich die vor zwei Seiten gepostete Funktion, einfach Copy&Paste.
Das Triebwerksmodell ist jetzt knüppelig schlecht, aber hab gerade nichts anderes zur Hand.
Aber es kommen brauchbare Daumenwerte raus, die der Realität entsprechen.

 

[Schorsch]

Leider besteht das Problem danach trotzdem noch: Wenn man das Programm mal laufen lässt, Link siehe unten, merkt man, dass mit der Höhe der Schub kleiner als der Widerstand wird, deshalb die negative Geschwindigkeitsänderung. Ich glaube, irgendwo muss man dem Programm noch sagen, dass bestimmte Minuswerte auf 0 gesetzt werden sollten (genau so wie ich es bei CL gemacht habe). Nur welche?

Liest nicht was ich schreibe, oder?
Mit Deinem Modell wird der Widerstand bei kleinen Geschwindigkeiten extrem groß.
Habe ich doch genau hergeleitet.

 

[LFeldTom]

Wenn man das Programm mal laufen lässt, Link siehe unten, merkt man, dass mit der Höhe der Schub kleiner als der Widerstand wird, deshalb die negative Geschwindigkeitsänderung. Ich glaube, irgendwo muss man dem Programm noch sagen, dass bestimmte Minuswerte auf 0 gesetzt werden sollten (genau so wie ich es bei CL gemacht habe). Nur welche?

Der Denkansatz ist gefährlich. Was mir nicht gefällt wird ignoriert. Negative Geschwindigkeitsänderungen sind doch nicht per se falsch. Dein Flugzeug verzögert halt. Geh mal zu einem Flugtag auf dem nicht nur F-16 & Co vorgeführt werden. Du wirst schnell sehen, dass steile Aufschwünge halt rasch enden weil einem die kinetische Energie aus geht. Wenn du eine B777 mit gamma = 18° nach oben prügelst geht der Mühle auch rasch die Luft aus. Gibt auch reale Beispiele wo sowas fatal daneben geht.

@LFeldTom

wollte ich umsetzen, hatte aber zur Folge, dass bei (gamma)=0 eine Höhenänderung stattgefunden hat.

Recht hast du - da fehlt der Auftrieb. Liefere ich gleich nach.

const double mag HTM/Javascript nicht. Es hat zur Folge, dass das Skript offenbar nicht ausgeführt wird, in meinem konkreten Fall bleibt die HTM-Seite leer bzw. hat nur die Hintergrundfarbe aus BGCOLOR in <BODY>.

Ich hab mal kurz nachgeschaut. JS kann das tatsächlich nicht. Lass das const double einfach weg und dann passt das wieder. JS ist halt sehr beschränkt wenn es um Typprüfungen geht. Anfänger lieben das in der Regel - im Laufe der Jahre lernt man sowas zu hassen ...

@all

Wer will, kann sich das Programm im Web ansehen oder beide Dateien herunterladen. Zu finden unter
http://www.stefanprobst1981.de/test.htm
http://www.stefanprobst1981.de/interpolation.js

Edit:
Gerade mal einen Blick in die interpolation.js geworfen. Ich kann nur hoffen, dass du das hast automatisch generieren lassen. Fast 4000 (!) Zeilen

 

[LFeldTom]

Nach 8 Minuten Flug in konstant 5800m bin ich jenseits der 600Kts - da klemmt auch der Horizontalflug noch.

 

[stefanpc81]

@Schorsch
Ist meine Bedingung

if (C_wert!=0&&pos_z==0) { CL = 0; }
else if (C_wert!=0) { CL = FG / C_wert; }
else { CL = 0; }

denn richtig? Beim Rollen am Boden, sagtest du, ist CL=0. Negatives CL gibt es ja wohl nicht?

@LFeldTom

Edit:
Gerade mal einen Blick in die interpolation.js geworfen. Ich kann nur hoffen, dass du das hast automatisch generieren lassen. Fast 4000 (!) Zeilen

Die 4000 Zeilen habe ich mit Hilfe von Excel teilweise automatisiert erstellt. Stichwort: VERKETTEN(x;y;z;...). Die Newton-Werte habe ich dann aus einem Tabellenblatt je Spalte mit copy&paste kopiert.

Zu letzterem: Man muss in der Programmierung auch bedenken, dass (gamma) auch negativ werden darf (im Sinkflug). Allerdings spuckt meine Funktion mit sinus oder cosinus dann aber einen (mathematisch an sich richtigen) positiven Wert aus. Da müsste man doch was anpassen müssen, oder?

 

[LFeldTom]

@LFeldTom

Die 4000 Zeilen habe ich mit Hilfe von Excel teilweise automatisiert erstellt. Stichwort: VERKETTEN(x;y;z;...). Die Newton-Werte habe ich dann aus einem Tabellenblatt je Spalte mit copy&paste kopiert.

Zu letzterem: Man muss in der Programmierung auch bedenken, dass (gamma) auch negativ werden darf (im Sinkflug). Allerdings spuckt meine Funktion mit sinus oder cosinus dann aber einen (mathematisch an sich richtigen) positiven Wert aus. Da müsste man doch was anpassen müssen, oder?

Sinus(gamma) bei negativem gamma wird negativ sein (gamma in sinnvollen Grenzen).

 

[LFeldTom]

So - ein wenig mit dem Code gespielt. Ohne große Optimierungen ist auf meinem ollen Notebook ein Zeitraffer mit etwa Faktor 25 drin - entsprechend 250 Aktualisierungen / Sek. Eine Frequenz von 1000Hz ist also durchaus machbar ( wenngleich das keinen echten Nährwert hat). Aber Performance ist wie vorhergesehen kein Problem.

Horizontalflug in 5800m Höhe mit Schubregler bei 90% erreicht langfristig 636 Kts (1178 Km/h). Davon träumt so mancher Tornado-Pilot (ohne Nachbrennereinsatz). Da solltest du mit Schorsch nochmal über weiteren Input verhandeln.

Ein wenig Refactoring war auch dabei. Berechnungen etwas kompakter, Ausgaben von den Berechnungen separieren, Variablen etwas umbenennen, Nachkommastellen auf sinnvolle Bereiche eingrenzen. Manches fand ich schwer les- / nachvollziehbar. Sowas packt man dann nicht an. Da bleibt noch jede Menge Platz wenn man sich austoben möchte. Modifizierter Code, wenn gewünscht, per Mail.

 

[stefanpc81]

@Schorsch

Die Werte aus dem Test erscheinen grundsätzlich realistisch. Eine B777 sollte in 1000m schon in der Lage sein mit ~5-7° zu steigen ohne dabei langsamer zu werden.

So, mit meinem letzten Stand des Programms habe ich das hier nochmal probiert. Mit 5° wird der Flieger nicht langsamer, mit >=6° schon.

Schorsch: Bei 18° Gamma und den besagten 295t Gewicht geht die Geschwindigkeit sehr schnell in den Keller. Da in jedem Zeitschritt der Auftriebsbeiwert berechnet wird, wird dieser unterhalb einer gewissen Geschwindigkeit irrsinnig groß.

Beispiel: Meine "B777" "fliegt" mit nur noch 50kts. Bei 295t wäre in Bodennähe mein
CL = (mg)/QdynS = 17.3
Natürlich wäre das richtige Flugzeug schon Jahre vorher im Strömungsabriss gewesen. Da dies hier aber nicht modlliert ist, berechnet sich der Widerstand zu:
CD = CD0 + k * (CL-CLmin)^2 = 22
Natürlich ein bekloppter Wert. Aber der Computer tut wie ihm befohlen.
Unser Flugmodell hat nun ein Widerstand, der etwa 380t entspricht. Dazu kommen sin(18°)*G.
In meiner Überschlagsrechnung komme ich auf etwa 1.5g, welche das Flugzeug nach hinten ziehen.

Sehr spaßig: nähernd sich die Geschwindigkeit null an (angenommen 1kts), erreicht mein Wert 3300g.
Wird die Geschwindigkeit negativ entspannt es sich wieder etwas, das resultierende CL steigt wieder. Es würde sich ein stabiler Flugzustand herausbilden, in der das Flugzeug mit einer stabilen negativen Geschwindigkeit "fliegt".

So lieber Kinder, das war "Numerik 101" und was passiert, wenn ich einfache Modelle mit nicht dafür vorgesehenen Eingaben konfrontiere. Und da sagt einer, dem Schorsch sein Modell sei falsch

LFeldTom: Horizontalflug in 5800m Höhe mit Schubregler bei 90% erreicht langfristig 636 Kts (1178 Km/h). Davon träumt so mancher Tornado-Pilot (ohne Nachbrennereinsatz). Da solltest du mit Schorsch nochmal über weiteren Input verhandeln.

Was schlägst du zur Verbesserung vor?

 

[LFeldTom]

Was schlägst du zur Verbesserung vor?

Schorsch fragen

 

[Spartacus]

Ich frage mich gerade, wieso jemand mit Mitte 30, der augenscheinlich
kein Pilot
kein Informatiker
kein Ingenieur
ist, überhaupt einen "Flugsimulator" programmieren will.
Man muss ja nicht alles sein, um das zu können, aber wenn man nichts davon ist, dann fehlt schon sehr viel.

Zum aktuellen Problem: Das Triebwerksmodell könnte ein Problem sein. In unterschiedlichen Höhen gibt es unterschiedliche Leistungen ab. Die maximal Dauerleistung ist auch eine andere, als die Startleistung.
Und mit jeder Sekunde verbraucht das Ding auch Sprit, was wiederum den Flieger leichter macht (und da geht es nicht um ein paar Gramm).

Evtl. guckst Du da mal näher rein.

Ach ja: Je schneller die Kiste fliegt, desto mehr Energie muss man aufwenden, um die Beschleunigung konstant zu halten.
Da das nicht endlos geht, wird also iregndwann die Beschleunigung auch kleiner, irgendwann dann auch 0 (mit Vollgas fährt Dein Auto ja auch nur eine bestimmte Höchstgeschwindigkeit, weil sich Luft- und Reibungswiderstand derart aufsummieren, dass sie der Vortriebsleistung entsprechen.

Viel Erfolg trotzdem

Spartacus

 

[Taliesin]

Horizontalflug in 5800m Höhe mit Schubregler bei 90% erreicht langfristig 636 Kts (1178 Km/h). Davon träumt so mancher Tornado-Pilot (ohne Nachbrennereinsatz). Da solltest du mit Schorsch nochmal über weiteren Input verhandeln.

Wenn du mit "90% Schubregler" sagen möchtest, dass 90% des Startschubs anliegen, dann ist das kein Wunder, dass die Geschwindigkeit eskaliert.

 

[LFeldTom]

Ich frage mich gerade, wieso jemand mit Mitte 30, der augenscheinlich
kein Pilot
kein Informatiker
kein Ingenieur
ist, überhaupt einen "Flugsimulator" programmieren will.
Man muss ja nicht alles sein, um das zu können, aber wenn man nichts davon ist, dann fehlt schon sehr viel.

Dem würde ich nicht zustimmen. Klar fehlt ihm viel - und ich würde jetzt am Ende kein für Luftfahrtanwendungen zertifiziertes Produkt erwarten. Wenn wir aber immer nur das machen was wir gelernt haben kommen wir am Ende nicht weiter. Ich mag das sehr wenn jemand mal aus seiner intellektuellen Komfortzone raus kommt und Neues probiert. Manchmal entdeckt man neue Fähigkeiten - und manchmal bleibt halt die Erkenntnis, dass man für das geplante nicht geschaffen ist. Man kann eigentlich nur gewinnen.

Und mit jeder Sekunde verbraucht das Ding auch Sprit, was wiederum den Flieger leichter macht (und da geht es nicht um ein paar Gramm).

Evtl. guckst Du da mal näher rein.

Ja und nein. Für größere Strecken ist das völlig korrekt. Bei ein paar Minuten sollte der Effekt noch überschaubar sein

Ach ja: Je schneller die Kiste fliegt, desto mehr Energie muss man aufwenden, um die Beschleunigung konstant zu halten.
Da das nicht endlos geht, wird also iregndwann die Beschleunigung auch kleiner, irgendwann dann auch 0 (mit Vollgas fährt Dein Auto ja auch nur eine bestimmte Höchstgeschwindigkeit, weil sich Luft- und Reibungswiderstand derart aufsummieren, dass sie der Vortriebsleistung entsprechen.

Das klappt ja auch soweit. Die Geschwindigkeit nähert sich asymptotisch der Höchstgeschwindigkeit für das Power-Setting an. Vmax ist in meinen Augen einfach zu groß. Zuviel berechneter Schub oder zu geringer Widerstand kann ich nicht sagen.

Wenn du mit "90% Schubregler" sagen möchtest, dass 90% des Startschubs anliegen, dann ist das kein Wunder, dass die Geschwindigkeit eskaliert.

So wie ich den Code gelesen hab wird der Schub berechnet aus
Standschub auf NN * PowerSetting * Faktor(Höhe, Speed)

PowerSetting ist hier 90%
Faktor(Höhe, Speed) ergibt sich aus dem Diagramm, welches Schorsch verlinkt hatte

Du hast wohl recht, dass die 90% zu hoch angesetzt sind.

80% -> 592,1 Kts (1097Km/h)
75% -> 567,6 Kts (1052Km/h)
70% -> Speed bricht komplett ein - wird negativ