Tutorial 4 Aufstiegssimulation

Ich glaube zwar inzwischen nicht, dass es jemand außer mir mein eigenes Programm nutzt, aber zum Abschluss der Dokumentation, hier nun die letzte Beschreibung der Aufstiegssimulation. Bei den Datendateien wurden inzwischen Rakete.rakdat, Delta, Atlas, Europa und China komplett umgestellt. Ich werde noch Saturn, Japan sowie zwei für die restlichen US- und Nicht-US-Träger erstellen, der Rest der alten Dateien, der auch viele hypothetische Träger enthält, wird nicht umgestellt. Sauber getrennt habe ich inzwischen existierende und nicht existierende Raketen. Die Letzteren findet man in „Nicht existent.rakdat“.

Inzwischen habe ich die Simulation von Freiflugphasen abgeschlossen. Die Einstellungen stecken in einem eigenen Menüpunkt unter „Bearbeiten → Einstellungen Parkbahn. Auch die Angabe von Startbedingungen habe ich in einen Dialog ausgelagert. Man kann nun das Startgelände auswählen und bekommt dann Starthöhe, Breitengrad gleich gesetzt. Meist muss man nur den Startazimut für eine andere Bahnneigung anpassen.

Zuerst mal was es mit der Parkbahn auf sich hat. Ich habe nicht vor alle Fälle zu bearbeiten. Meiner Ansicht nach, gibt es eine Freiflugphase und das ist das entscheidende Element einer Parkbahn, bei drei Fällen:

• Anhebung einer elliptischen erdnahen Bahn, z.B. bei der Vega. Die Ursprungsbahn hat ein Apogäum, das in der Höhe des späteren Apogäums liegt und ein Perigäum, das niedriger liegt, unter Umständen sogar noch unter der Erdoberfläche „off-perigree“.
• Eine Parkbahn, die in einen GTO endet. Bei dieser wird die Stufe wiedergezündet, wenn der Äquator passiert wird.
• Die Zirkularisierung eines GTO in den GSO.

Für die drei Fälle wird der Geschwindigkeitsvektor automatisch jeweils wie folgt gewählt:

• LEO-Anhebung: parallel zum momentanten Geschwindigkeitsvektor
• LEO → GTO Übergang: Vz Komponente ist 0, reduziert die Inklination-
• GTO → GSO Übergang: Vz Komponente ist entgegengesetzt der Geschwindigkeit in Z Richtung, sollte die Bahnneigung stark absenken.

In allen Fällen gilt: Da sich der Satellit laufend weiter bewegt dreht sich der Geschwindigkeitsvektor und man erhält meistens keine ganz kreisförmigen Bahnen. Dazu müsste man vorher den genauen Korrekturvektor berechnen, was ich noch nicht kann. Weiter unten gehe ich auf Wege ein, das zu optimieren.

Der allgemeine Ablauf einer Parkbahnsimulation ist dieser: Eine herkömmliche Simulation wird durchgeführt. Diese endet, wenn das Abbruchkriterium erreicht ist. Sie kann aber auch vorher abgebrochen werden, wenn die Anzahl an Sekunden beim Eingabefeld Freiflug-Start erreicht ist. Danach schließt sich eine Freiflugphase, an die abgebrochen wird, wenn Folgendes erreicht wird:

• GSO- und LEO-Anhebung: Apogäum erreicht
• GTO-Anhebung: Vorzeichenwechsel bei der Z-Koordinate des Orts (Äquator überschritten)
• Treibstoff verbraucht

Unabhängig davon kann die Freiflugphase fest nach n km oder n Sekunden beendet werden. Dann muss man die entsprechende Auswahl treffen. Im Normalfall sind die ersten beiden Optionen die besseren.

Eine Freiflugphase ist nur aktiv, wenn der Haken gesetzt ist.

In einigen Beispielen will ich das die Nutzung des Dialogs zeigen. Nehmen wir mal eine Falcon 9 in der GTO-Mission. Wenn wir den Haken für die Freifluphase entfernen bekommen wir eine 166 x 35800 km Bahn mit einer „Restmasse“ von 1594 kg. Für das tatsächliche Perihel, von 260 km das bei Falcon 9 Missionen auftritt müsste man die Bahn leicht anpassen, doch da ich die Freiflugphase veranschaulichen will lassen wir das mal, die vorliegende Bahn ist für eine Freiflugphase optimiert. Wenn wir die Punkte in der Tabelle unten ansehen, so stellen wir fest, das die Orbitsimulation nach 451,4 s startet. Dann hat die Falcon 9 einen stabilen Orbit (-23 x 380 km) erreicht. Das der erdnächste Punkt unterhalb der Erdoberfläche liegt, muss uns nicht kümmern, denn wir durchlaufen nicht mal einen halben Orbit, bevor wir die Oberstufe wiederzünden.

Mit den Daten kann man nun den Beginn der Freiflugphase festlegen. Ich habe als Startzeit 460 s eingetragen das erlaubt es den Orbit noch etwas anzuheben und vermeidet, dass er zu schnell wieder absinkt. Nach 460 s wurde ein 145 x 1.280 km Orbit erreicht. In dem Beispiel zündet die Falcon nach knapp 1355 s bei Überqueren des Äquators erneut und nach 1403 s hat sie Brennschluss. Sie erreicht einen 260 x 35800 km Orbit – genauso wie in Wirklichkeit. Vor allem ist die Bahnneigung kleiner. Diese war ohne Parkbahn 27,1 Grad. Mit Parkbahn sind es 20,8 Grad. Der nur in XY-Richtung gedrehte Geschwindigkeitsvektor senkte sie ab, kostete aber auch Nutzlast. Ohne Parkbahn ist nach meiner Simulation die theoretische Nutzlast rund 1500 kg höher als der Websitewert von SpaceX, mit Parkbahn schmilzt das auf 600 kg zusammen. Allerdings basiert die Rakete auch auf den Ankündigungen von SpaceX, die ich nicht für real halte und meine Simulation liefert meistens „bessere“ Werte als die Wirklichkeit, allerdings nicht mit so großer Abweichung. Normal sind etwa 3-5 %.

Für die Freiflugphase werden keine Daten erhoben. Man sieht dies in den Diagrammen an einer graden Linie zwischen dem letzten angetriebenen Punkt und dem Beginn der Wiederzündung. Sie machen keinen Sinn, außer bei Höhe. Die Höhe kann man im Diagramm „Bahn“, das die Höhe relativ zum Erdmittelpunkt auch über die Freiflugphase wiedergibt aber sehen. Kommt eine Rakete nicht zur Wiederzündung, so kann man dieses Diagramm konsultieren, ob sie zwischendurch abgestürzt ist (dann war die Bahn nicht stabil, späteres Einsetzen der Freiflugphase sinnvoll). Man sieht es auch in der Ausgabe, wenn dort bei Freiflugphase 0 steht oder die letzte Höhe 80 km oder weniger war – dann stoppt die Simulation automatisch. Ein zweiter Grund kann sein, dass der Wiederstartpunkt falsch gewählt ist, z.B. nach n km die Rakete aber, wenn die Freiflugphase einsetzt, schon weiter als n km von der Erdoberfläche entfernt ist.

Etwas komplexer ist es bei dem Angleichen eines Apogäums. Das Verhalten ist das gleiche bei GTO → GSO Transfers oder einfachen Apogäumsanhebungen. Auch hier modelliert man zuerst eine Transferbahn, zweckmäßigerweise, indem man die Freiflugphase zur Ermittlung der Übergangsbahn abschaltet. Das Apogäum sollte in der Höhe des späteren Apogäums liegen. Es kann aber auch etwas drunterliegen. Dann schaltet man die Freiflugphase ein und den Punkt „Wenn Apogäum erreicht“ und simuliert erneut. In der Regel wird man keine richtige Kreisbahn erreichen, vor allem wenn der Geschwindigkeitsunterschied groß ist, wie bei GTO-Bahnen im Apogäum oder der Schub des Triebwerks klein. Das ist schwer vermeidbar, da der Geschwindigkeitsimpuls immer in augenblicklicher Flugrichtung geht, die sich laufend ändert.

Hier muss man etwas probieren. Da jede Zündung das Apogäum ausweitet, kann man es probieren das Apogäum der Startbahn niedriger als das spätere Zielapogäum zu legen. Bei der Vega z.B. 600 km Höhe, wenn der Orbit 700 km hoch sein soll. Ebenso kann man im Menü „Parameter verändern“ das Apogäum oder Perigäum anpassen. Man kann auch mit dem Start und dem Ende der Freiflugphase spielen. Das Ende kann auch als km Distanz angegeben werden, wenn man vor Erreichen des Apogäums erneut zünden will. Der erste Punkt in dem Menü fügt dagegen eine Freiflugphase zwischen zwei Stufen ein. Das ist nicht dasselbe, sondern nur eine verlängerte Zeit zwischen Stufentrennung und Zündung. Zudem kann dieser Punkt den Zündzeitpunkt anpassen. Das ist bei der Freiflugphase unnötig, da in dieser Zeit gar keine Simulation des Schubs stattfindet. Die angetriebene Simulation bleibt praktisch stehen, bis die Wiederzündung erfolgt.

Für die Festlegung des Zeitpunktes hilft ein Blick auf die Bahnpunkte in der Tabelle unten. Das Zwischenapogäum sollte in der Nähe des späteren Apogäums liegen. Bei schubschwachen Stufen wie der letzten der Vega sollte das Perigäum nicht zu tief liegen, sonst kann die Rakete dies nicht mehr ausgleichen oder es resultieren zu elliptische Umlaufbahnen. Hier schlägt ein Manko des Programms zu – es optimiert rein auf Nutzlast bzw. Bahn und lässt „natürliche“ Nebenbedingungen unter den Tisch fallen. Eine Rakete kann z.B. sich nicht abrupt drehen. Das Programm hat keine Probleme einen Datenpunkt als optimal zu errechnen, indem die Rakete nach 30 s einen Winkel von 30 Grad zur Erdoberfläche hat. Normale Rotationsraten bewegen sich soweit ich das weis zwischen 0,6 und 1,1 Grad pro Sekunde. Eventuell bessere ich das bis zum Erscheinen des Artikels, den ich im voraus schreibe noch nach.

Eine Simulation, die nur auf das Apogäum optimiert und so eine Vorlage für eine Transferbahn liefert bevor man die Simulation mit Freiflugphase macht, ist der zweite Punkt im Modus „Nur Apogäum“. Aber bitte auch einen Blick auf das Perigäum werfen bzw. den Treibstoffverbrauch zum Erreichen des Zielperigäums. Notfalls in der frühen Phase der Bahn weniger steil starten.

Im Prinzip kann man mit dem Punkt alle Parkbahnen erledigen, auch für interplanetare Missionen, nur macht es bei denen meist keinen Sinn. Hier dient eine Freiflugphase nicht dazu die Nutzlast zu erhöhen, sondern einen bestimmten Punkt im Orbit zu erreichen. Eine Ausnahme ist gegeben, wenn die Oberstufe extrem schubschwach ist, dann kann eine Parkbahn zuerst schwach elliptisch sein, und dann beim nächsten Durchlaufen des Perigäums aufgeweitet werden. Das minimiert die Gravitationsverluste. Gemacht wurde es meines Wissens nach nur einmal beim Start von Rosetta, wo die EPS mit Rosetta auf eine Bahn mit einem Apogäum von etwa 2900 km gebracht wurde und beim Durchlaufen des Perigäums wiederzündete. Rein theoretisch könnte das die Nutzlast bei kleinem Schub der Oberstufe steigern. So könnte man die erste Freiflugphase der Breeze simulieren. Die anderen nicht, weil ich nur eine Freiflugphase vorgehen habe.

Zuletzt noch ein Beispiel wie man nicht virtuelle, aber trotzdem nicht existierende Träger simuliert. Ich habe überlegt, ob ich das Beispiel bringe, weil erfahrungsgemäß sich dann wieder Leute melden, die sich nicht um den Rest des Artikels und seiner drei Vorgänger kümmern und zu faul oder sonst wie gehindert sind, selbst zu simulieren (ist nun ja möglich, ich gebe zu: die ganzen Daten einzugeben und Bahnen zu optimieren kann bei manchen Trägern eine halbe, bis eine Stunde dauern). Es ist die Verifizierung folgenden Tweets:

„@TobiasVdb The F9 booster can reach low orbit as a single stage if not carrying the upper stage and a heavy satellite.“

Nun bei einem Strukturfaktor von 30 (nur für die Booster der Falcon Heavy, die normale Falcon 9 Erststufe trägt noch den Stufenadapter zur Zweitstufe und der ist lange wegen der großen Expansionsdüse des Merlin) ist, das nur nach Ziolkowski, leicht ausrechnet. Nehmen wir den Vakuum-Impuls von 3050 m/s der aktuellen Falcon 9, so erhalten wir:

v = 3050 m/s * ln (30) = 10373 m/s.

Der Bodenimpuls ist nicht bekannt bei gleichmäßigem Treibstofffluss aber proportional zum Schub und der beträgt 7607 zu 8227 also 92,4 %. Mit 92,4 % * 10373 m/s kommt man immer noch auf 9591 m/s.

Die Falcon 9 hat ohne Erststufe eine hohe Beschleunigung und kurze Brennzeit. Die Gravitationsverluste dürften also klein sein. Feststoffraketen mit ähnlicher Brennzeit kommen auf 1100 bis 1200 m/s Gravitationsverluste. Dies addiert zur Orbitalgeschwindigkeit von 7800 m/s und man kommt auf 9.000 m/s. Da sind beide Werte drüber. Also hat de Mann recht, wenn man den Aufstieg nicht simulieren kann.

Das Problem: Damit das Perigäum hoch genug ist damit die Rakete nicht wieder nach einem Umlauf verglüht sollte ein guter Teil der Beschleunigung oberhalb einer sicheren Höhe erfolgen. Eine sichere Höhe sind so etwa 160 km, da ist die Bahn über 1-2 Tage stabil, genug Zeit um einen Satelliten mit eigenem Antrieb in eine höhere Bahn zu verschieben.

Das schafft die Falcon 9 mit ihren 162 s Brennzeit nicht. Nach der Zeit hat sie noch nicht mal die 160 km Höhe erreicht, was logisch ist, sie müsset dann im Mittel um 1 km pro Sekunde steigen! Ihr könnt gerne von einer Falcon 9 die zweite Stufe entfernen und mit Bahnen experimentieren – ihr werdet immer Bahnen bekommen die elliptisch sind, deren Perigäum aber unter 160 km liegt.

Nun sind die Triebwerke aber auf 60 % drosselbar und das habe ich ausgenutzt. In der zweiten Simulation habe ich die Erststufe gedanklich in zwei Stufen aufgeteilt. Die eine arbeitet mit 100 % Schub vom Start an, die zweite mit 60 % Schub. Sie wird „gezündet“ wenn die Erste ihren Treibstoff verbraucht hat. Die Leermasse der „ersten“ stufe ist natürlich 0, es ist nur Treibstoff, der verbraucht wird. Als Zeitpunkt habe ich 2,5 g Beschleunigung festgelegt, bei 60 % Schub sinkt die Beschleunigung dann auf 1,5 g ab. Wenn ihr wollt, könnt ihr mit dem Zeitpunkt noch etwas spielen.

Das addiert Brennzeit, so kommt man auf 230 s Brennzeit. Es ist aber noch zu wenig um einen stabilen Orbit zu erreichen. Zu Brennschluss ist die Rakete in 100 km Höhe und hat eine elliptische Umlaufbahn mit knapp 120 km Perigäum erreicht. Trotz mehrerer Versuche habe ich kein höheres Perigäum erreicht. Das ist also instabil. Immerhin, in diesen „off-Perigree“ Orbit kann sie eine Menge Nutzlast befördern: 10 t in einen 90 x 300 km Orbit. Der müsste dann vom Kunden aber schnell angehoben werden.

Doch bei heutiger Vorgehensweise bei denen einige Tage mit Checks des Satelliten vergehen, kann man sagen: die Aussage stimmt nicht zumindest erreicht sie keinen stabilen Orbit, wohl aber die Orbitalgeschwindigkeit.

Ach ja noch außer der Reihe: Trau keiner Statistik, die Du nicht selbst gefälscht hast. Nach Ingo ist ja die Oberstufe der Falcon 9 besser als alles andere. Ich habe nur zum Spaß mal die 5 t seiner Simulation mit der Falcon 9 Oberstufe und einer Centaur als C3-Simulation (man erreicht ja dann Fluchtbahn) laufen lassen und siehe da: Falcon 9 c3 von 16,8, SEC-Centaur auf Falcon 9: 21,5 km²/s² – nicht viel, aber eben deutlich mehr. Tja es kommt immer auf das Gesamtsystem an. Man vergleicht ja auch nicht Motoren, sondern Autos, sonst wäre jeder LKW besser als ein Rennwagen …. Um Fragen von Ingo vorzubeugen: Die Geschwindigkeit ist bei der Falcon 9 höher, weil man bei ihr die Bahn niedrig halten kann durch die geringe Brennzeit. Die Centaur hat erst in 800 km Brennschluss, in dieser Höhe braucht sie aber eine kleinere Geschwindigkeit um die Fluchtgeschwindigkeit zu erreichen und das C3 gibt ja, an was man zusätzlich zur Fluchtgeschwindigkeit noch im Unendlichen übrig hat. Die 21,2 km²/s² sind übrigens höher als beim Tesla Roadster mit c3=12.

Ihr findet alle Falcon 9 Simulationen unter SpaceX-Nicht-Existent.rak