Komet Leonard begegnet der Venus
Komet C/2021 A1 Leonard, mit einem Kerndurchmesser von nur etwa 1 km, ist aktuell vor Sonnenaufgang im Osten zu beobachten. Am 18.12.2021 gegen 02:10 UTC wird Leonard laut JPL Horizons die Venus im Abstand von knapp 4.3 Millionen km (0.027 AE) passieren.
Leonard ist auf einer retrograden Bahn mit einer Inklination von 133 Grad. In der obigen Grafik kommt er von rechts oben und zieht nach links unten davon. Er durchquert das Sonnensystem also im Uhrzeigersinn, entgegen der Flugrichtung aller Planeten.
Die Bahn von Leonard ist nicht nur retrograd, sondern jetzt auch hyperbolisch. Er wird am 3. Januar sein Perihel durchlaufen und dann auf Nimmerwiedersehen verschwinden. Von unseren Breiten aus kann der Komet bis zum 12.12. in den frühen Morgenstunden beobachtet werden. Seine Helligkeit ist ziemlich hoch, aber die Aufhellung des Osthimmels vor Einsetzen der Dämmerung macht die Beobachtung schwieriger. Die Grafik unten zeigt die Bahn durch das Sternbild Schlangenträger vom 9.12. bis 13.12., jeweils simuliert für 07:00 MEZ.
Danach werden wir ihn nicht mehr beobachten können. Auf der Südhalbkugel sollte es jedoch spätestens im Januar wieder Beobachtungsmöglichkeiten in den Abendstunden geben. Allerdings wir der Komet dann nicht mehr so hell sein wie jetzt mit einer Magnitude von heller als +5mag.
Und jetzt noch ein anderes Thema …
Meine Abteilung ist mitten in einer tiefgreifenden Umstellung der Analysesoftware. Die alte Software war noch weitgehend in Fortran geschrieben, Teile davon stammen aus den 70ern. Mit den neuen Systemen wird die Grundfunktionalität in C++ entwickelt; die Anwendungen werden mit Python erstellt.
Allerdings gibt es auch Tools, die entweder erst später oder gar nicht in das neue System übernommen werden, entweder weil es dort bereits andere Werkzeuge mit ähnlicher Funktionalität gibt oder weil man sie dort nicht braucht, zumindest nicht sofort. Als langjähriger Mitarbeiter habe ich noch eine ganze Menge solcher Software, die ich einfach noch so lange verwenden werde, wie ich hier bin.
Nun haben wir allerdings auch einen Wechsel der Betriebssystemversion vorgenommen. Dabei wurde die Lizenz für den bisher verwendeten Fortran-Compiler gekündigt. Die alten Säcke wie ich, die noch mit Fortran arbeiten, müssen jetzt mit dem gnu-compiler vorlieb nehmen. Eigentlich kein Problem, dachte ich. Ich habe ja nie irgendwelche Non-Standard-Sachen in meinem Code verwendet, dachte ich. Einfach alles rekompilieren, und fertig ist der Lack, dachte ich.
Irrtum! Gut, der neue Compiler ist etwas strenger als der alte, und ich musste einigen schlampig programmierten Code geradeziehen. Damit hatte ich auch gerechnet. Irgendwann bemängelte der Compiler keinen “Error” mehr und die “Warnings” umfassten nur noch Dinge, von denen ich wusste, dass das in der Praxis nichts ausmacht. Also baute ich meine Systeme wieder auf und wollte mit meiner normalen Arbeit loslegen, aber es lief … gar nichts!
Es ist nicht so, dass die Software geschlossen den Dienst verweigerte. Es kam aber zumeist komplett anderes heraus als vor dem Umstieg. In der Regel liefen die Programme einige Hundert Schritte lang richtig, aber dann ging es vollkommen verquer. Ich hatte den Fehler bald auf eine geringe Anzahl von Subroutines in einer nicht von mit stammenden Bibliothek eingekreist. Leider handelte es sich um ziemlich grundlegende Funktionalität, die ich einfach überall brauche. Nach einem Blick in die betreffenden Quellcodes war mir klar, dass ich hier Hilfe brauche.
Wenn man Glück hat, dann gibt es da einen oder eine, der oder die weiß, wie man Sachen hinkriegt. Wir haben so einen. Ich rief ihn an und beschrieb ihm das Problem.
Er: Du weißt also, welche Subroutines das Problem sind.
Ich: Ja, es sind nur ganz wenige, und die haben alle mit der Subroutine ——— zu tun.
Er: OK, konzentrieren wir uns also auf die. Wer hat die geschrieben?
Ich: Keine Ahnung, woran kann ich das denn sehen?
Er: Na, das wird ja wohl im Header stehen, oder in Kommentaren.
Ich: Header? Kommentare? Du beliebst zu scherzen.
Er: OK …. wie sieht der Code aus?
Ich: Ehrlich gesagt, als ob sich ein Schwein in ******* gesuhlt hätte.
Er: Aha! So schlimm? Dann war das der XXXXXX.
Ich: Der ist aber vor 10 Jahren in Rente gegangen.
Er: Genau. Also haben wir ein Problem. Oder eher: du hast ein Problem.
Ich: Danke, Mann! Genau das wollte ich jetzt hören.
Er: Moment … da fällt mir was ein. Hat der irgendwo Variablen mit SAVE deklariert?
Ich: Deklariert? Machst du Witze? Der hat noch nicht einmal eine einzige Variable explizit deklariert. Alles implizit.
Er: Dann könnte es genau daran liegen. Der Gnu-Fortran Compiler reinitialisiert per default alle Variablen innerhalb einer Routine bei jedem Aufruf. Es sei denn, du setzt den Flag -fno-automatic.
Ich: Wie jetzt! Du willst mir jetzt nicht sagen, dass eine Compileroption darüber entscheidet, was die Software für numerische Ergebnisse ausspuckt.
Er: Pup’ hier nicht rum und versuch’ das mit dem Flag. Jede Wette, das war’s.
Und er hatte Recht. Das war’s wirklich.
Erklärung: Variablen innerhalb von Fortran-Subroutines können statisch sein, dann behalten sie ihren Wert vom letzten Aufruf bei, wenn die Routine wieder aufgerufen wird. Bei alten Compilern war dies das Standardverhalten, und sehr viele Softwareentwickler verließen sich einfach darauf. Aber eigentlich war das ziemlich gefährlich, wenn sie nicht ausdrücklich die Variablen, die ihren Wert beibehalten sollten, mit “SAVE” als statisch deklariert hatte. Mir ist nicht bekannt, ob man sich auch früher schon blind darauf verlassen konnte, dass die entsprechenden Speicherbereiche wirklich reserviert bleiben würden. Man sollte so etwas jedenfalls nicht tun, und man sollte sich der Tatsache bewusst sein, dass Fortran eine Programmiersprache ist, wo ein Compiler-Flag darüber entscheidet, ob ein Programm mit identischen Eingabedateien als Ergebnis 5.000 oder -3.2986E-28 berechnet.
Was das implizite Deklarieren von Variablen angeht: zumindest alte Dialekte von Fortran gestatteten noch, als erstes Statement im Code so etwas zu setzen wie “IMPLICIT REAL*8 (A-H, O-Z)”. Wenn man das machte, war jede Variable, die mit einem Buchstaben zwischen a und h oder zwischen o und z begann, automatisch eine acht-byte-Gleitkommazahl, alle mit Buchstaben zwischen i und n beginnenden waren Variablen, die Ganzzahlwerte aufnehmen konnten.
Wenn man nun aber einer Variablen a0 einen Wert zuwies und sich irgendwo vertippte und anstatt der Variablen a0 versehentlich “ao” eingegeben hatte, dann bemängelte der Compiler das nicht und verwendete einfach die Variable ao in der Rechnung. Diese Variable hatte aber nicht den Wert, den sie haben sollte, sodass auch alles, was folgte, nicht das war, was man berechnen wollte.
Der Versuch, durch den Verzicht auf die explizite Deklaration ein paar Minuten Zeit zu sparen, führte dann schnell mal zu aufwändiger Fehlersuche. Da solche Programmierer meist generell schlampig arbeiteten, beispielsweise indem sie nichts dokumentierten, konnte die Fehlersuche beliebig kompliziert werden.
Sehr interessant was sich da im Weltraum abspielt.
Mein Mitgefühl zu den Softwareproblemen. Meine eigenen Programme, ich kann sie nicht mehr vollkommen verstehen, ich war auch zu faul, ein paar Kommentare dazwischen zu machen. von der schlampigen Strukturierung mal ganz abgesehen.
Ich habe das Programmieren damals anhand einer gemeinsamen Programmentwicklung von einem Meister gelernt. Da wurde sehr auf Ordnung und Strukturierung wert gelegt. Das war “Für das Leben lernen”. Damals war man als “EDV-ler” auch noch eine angesehene Person im Unternehmen.
“Früher” (TM) war man als technischer Experte, sei es nun EDV oder irgendetwas anderes, was das Kerngeschäft des Unternehmens berührt, eine angesehene Person. Heute gilt man nur in einer Managementfunktion etwas.
Allerdings, da beißt die Maus keinen Faden ab, die betreffende Software ist auch von einem solchen (durchaus zu Recht) angesehenen technischen Experten entwickelt worden, und es fällt mir eher schwer, dessen Leistung uneingeschränkt positiv zu bewerten.
Einer seiner nicht minder angesehenen Expertenkollegen hat sogar reihenweise interne Preise für vorbildliche Softwareentwicklung abgeräumt. Wie er das gemacht hat? Ganz einfach – jedes Mal, wenn er in seinem chaotischen Code etwas korrigieren oder umräumen musste, hat er den alten Code einfach auskommentiert. Der Beurteilungsalgorithmus zählte aber einfach nur die schiere Anzahl an Kommentarzeilen – wer davon am meisten hatte, hatte gewonnen.
Ja, leider ein bisschen makaber. Und auf einer solchen Basis ruht nun unser Softwaregebirge, das immer fundamentaler für unsere Zivilisation wird. Das ist fast wie die Sache mit dem Weltraummuell. In 2040 soll schon jede 5. Mission statistisch gesehen daran scheitern.
Ich denke, Unternehmen sollten einfach alle 20 Jahre oder so Geld in die Hand nehmen und ihre Softwarearchitektur neu entwickeln, so wie das in meiner Abteilung gerade gemacht wird. Der ganze unwartbare Zombie-Code fliegt dabei raus und man hat dann erst mal ein modernes, leistungsfähiges System, das dann allerdings auch bald wieder anfangen wird zu altern, in dem irgendwelche Leute herumfuhrwerken werden usw. Softwareentwickler werden also immer ihr Auskommen haben. Das ist die gute Nachricht.
Weltraummüll ist in der Tat ein ganz übles Problem, aber es gibt auch Hoffnung. Ich denke, es wird in absehbarer Zeit das große Aufräumen beginnen. Das wird allerdings nichts an der Anzahl keiner Trümmerteile aus zurückliegenden Fragmentationsereignissen ändern, sondern sich erst einmal auf die Entfernung defekter Satelliten und bald hoffentlich auch ausgebrannter Raketenstufen konzentrieren. Ich würde mir jedoch wünschen, dass Europa diese Aufräumarbeiten energisch vorantreibt, und nicht so halbherzig wie jetzt noch.
Ich habe auch einmal eine ganze Nacht nach einer “0” gesucht,
die ein “O” hätte sein sollen, ohne zu wissen, wonach ich suche.
—–
Graf Hombug liebt große Explosionen, und hyperbolische
Kometen haben in der Nähe der Erde mindestens
4,21 mal 10 hoch 4 Meter pro Sekunde, das ist die
Fluchtgeschwindigkeit von der Sonne im Erdabstand,
1 mal 10 hoch 12 Kilogramm, das ist ein
Kubikkilometer bei einer mittleren Dichte von
1000 Kilogramm pro Kubikmeter,
8,862 mal 10 hoch 20 Joule kinetische Energie,
4,184 mal 10 hoch 15 Joule pro Megatonne TNT Sprengkraft,
2,118 mal 10 hoch 5 Megatonnen TNT Sprengkraft.
@TheKarlBednarik: Wenn Sie den Programmierfehler selbst eingebaut haben, dann ist es ausgleichende Gerechtigkeit, wenn Sie sich später mit der Suche danach die Nacht um die Ohren schlagen müssen.
Graf Homburg müsste noch ein paar mehr Rechenschritte durchführen – den Mindestwert der hyperbolischen Annäherungsgeschwindigkeit an die Erde berechnen, und daraus dann die Eintrittsgeschwindigkeit in die Erdatmosphäre. Dann erst hat er die umgesetzte kinetische Energie.
Das allerdings ist ein ziemlich zahmer Fall. Der Komet kann da durchaus auch vollkommen retrograd sein, mit einer Inklination relativ zur Ekliptik von 180 Grad. Dann ist die hyperbolische Annäherungsgeschwindigkeit relativ zur Erde richtig groß, und alles, was daraus folgt auch.
Was sagt Graf Homburg dazu?
Komet C/2021 A1 Leonard fällt also aus dem Rahmen. Er ist kein Wiederkehrer und passt mit seiner retrograden, stark inklinierten Bahn nicht so recht in unser Sonnensystem – obwohl er unzweifelhaft seinen Ursprung irgendwo weit draussen, aber innerhalb unseres Sonnensystems hat. Jetzt aber verlässt er unser Sonnensystem und wird vielleicht irgendwann viel später zum Oumuamua eines anderen Sonnensystem. Nun, nicht wirklich, denn Oumuamua war ja ein echt interstellares Objekt und nicht nur ein Streuner, der mal kurz seinen Heimatstern verlässt wie das Leonard jetzt tut.
Die Bahn des Kometen Leonard war vor diesem Periheldurchgang noch ganz knapp elliptisch. Im März 2020 wurde seine Bahn dann hyperbolisch. Der energetische Unterschied ist da nicht mehr sehr groß. Die retrograde Bahn und die fast-parabolischen Bahnparameter weisen auf einen Ursprung in der Oortschen Wolke hin, also in der Tat noch innerhalb des Sonnensystems. Wenn der Komet in vielen, vielen Jahren einmal die Oortsche Wolke hinter sich gelassen haben wird, dann wird seine Entfernungsgeschwindigkeit nur noch sehr gering sein, sodass es entsprechend lange dauern dürfte, bis er wirklich einmal einem anderen Stern nahe kommt.
Hallo Michael Khan.
Es kommt auf jeden Fall noch die Fluchtgeschwindigkeit der Erde von 11186 m/s dazu.
Die mittlere Orbitalgeschwindigkeit der Erde von 29780 m/s kann je nach dem Auftreffwinkel mehr oder weniger dazu kommen, oder abgezogen werden.
Graf Homburg sagt immer: “Wir brauchen eine größere Raumflotte.”
@TheKarlBednarik: Ich bin sicher, Herr Homburg (Adelstitel werden zu seiner Zeit bereits längst der Vergangenheit angehören) wird seinen Helm absetzen, die Fingerknöchel knacken lassen und es richtig nachrechnen.
Also:
Bei frontaler Kollision mit der Erde, wenn der Komet auf einer quasi-parabolischen Bahn hereinkommt, deren Inklination 180 Grad zur Ekliptik beträgt und deren Perihelradius bei 1 AE liegt:
Hyperbolische Ankunftsgeschwindigkeit relativ zur Erde: 29.77 km/s * (sqrt(2)+1) = 71.87 km/s
Vis-Viva-Gleichung v = sqrt (mu * (2/r – 1/a))
mit
v = Bahngeschwindigkeit [km/s]
mu = Gravitationsparameter des Zentralkörpers (für die Erde 3968600.44 km^3/s^2)
r = Bahnradius [km]
a = Große Halbachse [km]
Auf der Asymptote der Ankunftshyperbel, wo die Relativgeschwindigkeit wie oben berechnet 71.87 km/s beträgt, ist der Abstand sehr groß, daher ist 2/r vernachlässigbar und die große Halbachse berechnet sich zu
a = – mu / v^2 = -77.17 km
Beim Einschlag (die Atmosphäre kann man in diesem Fall außen vor lassen) ist die Bahngeschwindigkeit mit der vis-viva-Gleichung zu berechnen, was Herr Homburg natürlich weiß:
v_i = 72.73 km/s
Der nur geringe Geschwindigkeitszuwachs zwischen großer Entfernung und Impakt ist der hohen hyperbolischen Ankunftsgeschwindigkeit geschuldet. Dieser Wert gilt unabhängig davon, ob der Einschlag mit flachem oder steilem Winkel erfolgt.
Man kann jetzt natürlich noch die tatsächliche Relativgeschwindigkeit berechnen, bei der die Parameter der hyperbolischen Bahn und die geographische Breite des Einschlagsorts eine Rolle spielen, aber bei einer solchen Geschwindigkeit macht das keinen großen Unterschied mehr.
Angenommen, der Komet hat einen Durchmesser von 5 km, dann berechne ich unter Annahme einer eher geringen mittleren Dichte von ca. 1250 kg/m^3 eine Masse von 8.2 E13 kg. Die kinetische Energie liegt damit bei etwa 2E23 J, d.h., etwa 5.2 E7 Megatonnen TNT. 52 Millionen Megatonnen oder 52 Teratonnen. Etwa eine Million “Zar-Bomben” gleichzeitig gezündet.
Hallo Michael Khan.
Danke für die Informationen, denn ich lerne immer gerne etwas vom Fachmann dazu.
Nur noch eine laienhafte Frage:
Wenn ein Objekt aus dem fernen Weltraum bereits mit einer hohen Anfangsgeschwindigkeit auf die Erde zukommt, dann wird es zwar durch die Gravitation der Erde nur noch ein wenig schneller, aber die potentielle oder kinetische Energie, die der Fluchtgeschwindigkeit der Erde entspricht, die müsste eigentlich immer dazukommen?
Es kommt von der hyperbolischen Annäherung bis zum Einschlag genau die Geschwindigkeit hinzu, die sich aus der vis-viva-Gleichung ergibt, denn die ist ja nichts anderes als die Energieerhaltung.