We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Open Source im BACARDI Projekt

00:00

Formal Metadata

Title
Open Source im BACARDI Projekt
Title of Series
Number of Parts
94
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Wir präsentieren den “Backbone Catalogue of Relational Debris Information” (BACARDI) [2]. BACARDI ist Teil eines Vorhabens des Deutschen Zentrums für Luft- und Raumfahrt e.V. (DLR) zur Erfassung und Nachverfolgung von kooperativen und unkooperativen Objekten im Erdorbit. Aufbauend auf Open Source Software entsteht mit BACARDI ein System für den Einsatz im Deutschen Raumfahrkontrollzentrum, das Informationen über alle bekannten orbitalen Objekte verwaltet und aufbereitet. Im Vortrag werden wir zunächst erläutern, warum Raumfahrtrückstände überhaupt problematisch sind und welche Gefahren für aktive Objekte und Menschen im Erdorbit entstehen. Daran anschließend werden wir darlegen, warum wir in der Entwicklung Open Source Software und Bibliotheken einsetzen und weshalb wir uns für Django [3] und Apache Airflow [1] als Kernkomponenten entschieden haben. Als Schwerpunkt stellen wir die Eigenentwicklung F2x [4] vor. Diese Open Source Software dient der Anbindung von Fortran-Software an das BACARDI- System. Im Rahmen des Vortrags erläutern wir, welche Vorteile diese Software für unseren Einsatzzweck gegenüber anderen Lösungen bietet und welche Vorteile sie für andere Projekte bieten kann. Auf der BACARDI Datenbank setzen Prozesse auf, die die dort hinterlegten Orbitinformationen verarbeiten um zum Beispiel Kollisionswarnungen zu generieren. Als Betreiber von Satelliten ist das DLR direkt von Gefahren wie Kollisionen betroffen. Es forscht deshalb aktiv auf diesem Gebiet und entwickelt zur Unterstützung der Raumflugbetriebe unter anderem Modelle und Software zur Berechnung orbitaler Flugdynamik.
Open sourceSoftwareOpen sourceXMLUMLLecture/Conference
Open sourceHTTPSoftware engineeringSoftware engineeringMoment (mathematics)Computer animation
Software developerPILOT <Programmiersprache>Set (mathematics)Point of saleSoftware engineeringComputer programSoftware developerPILOT <Programmiersprache>SoftwareCurveComputer animation
Context awarenessPhysical quantityOrbitComputer animation
Context awarenessVideo trackingSatelliteVideo trackingComputer animation
Web pageSatelliteOrbitExplosionCollisionNumberTechnical failureComputer animation
Object (grammar)LengthOrbitLecture/ConferenceComputer animation
Computer programmingAlgorithmMittelungsverfahrenComplete metric spaceParticle detectorPredictionComputer programmingAlgorithmCollisionDatabaseComputer hardwareObject (grammar)SoftwareInequality (mathematics)Computer animation
Continuous trackDatabaseAutocovarianceParameter (computer programming)Drag (physics)ProzessorOrbitSpeciesPAPMoment (mathematics)InformationObject (grammar)Computer animation
HTTPDjango <Informatik>Scheduling (computing)ArchitectureBerechnungInformationComponent-based software engineeringScheduling (computing)AlgorithmDistanceDjango <Informatik>Systems <München>DatabaseComputer animation
Open sourceCodeHigh availabilityOperating systemPerimeterSoftwareCodeOpen sourceAPIInterface (computing)Web pageSoftwareApache <Programm>PerimeterDjango <Informatik>FRAMEWORK <Programm>Computer animation
FRAMEWORK <Programm>Django <Informatik>Patch (Unix)Term (mathematics)Mobile appVideo trackingAPIDatabaseMAPPERMobile appPhysical quantityDatabaseArchitectureDatabaseObject (grammar)Table (information)SoftwareLecture/ConferenceComputer animation
FRAMEWORK <Programm>AutomationComputer programApache <Programm>SoftwarePatch (Unix)ScalabilityComponent-based software engineeringKopplung <Physik>MiddlewareFRAMEWORK <Programm>AutomationProcess (computing)ComputerMoment (mathematics)Scripting languageProzessorMobile appComputer animation
SoftwareEigenvalues and eigenvectorsFORTRANOpen source
Version <Informatik>CompilerBIND <Programm>Template (C++)ImplementationFORTRANCode generationSource codeARDEN <Programmiersprache>Set (mathematics)CodeFORTRANInformationComputational scienceTemplate (C++)ParsingRegular expressionSource codeSoftware developerFactorizationData typeAbbildung <Physik>UpdateOpen sourceCompilerComputer animation
BIND <Programm>FORTRANInterface (computing)CompilerProgramming languageFORTRANComputer animation
PolynomialTypFORTRANImplementationFeedbackGRADECodeMicrosoftSAP <Marke>Computer animation
BenchmarkGirderVelocityGraphics tabletComputer programComputer animation
MIKE <Programm>FORTRANCompilerFORTRANSupremumForceComputer animation
FORTRANIntelGNU <Software>BIND <Programm>Code refactoringSoftwareVideo trackingOpen sourceComputer programmingDjango <Informatik>CompilerInformationCodeApache <Programm>Student's t-testCollisionHand fanFORTRANOpen sourceSoftwareMoment (mathematics)Field extensionCommon Language InfrastructureComputer animation
Heat transfer coefficientDirection (geometry)SupercomputerFORTRANCompiler
SoftwareCodeObject (grammar)CoroutineFORTRANSoftwareProgramming languageBerechnungCompilerCompilerALT <Programm>Moment (mathematics)Lecture/Conference
openSUSEXMLComputer animation
Transcript: German(auto-generated)
Heute mal, wie wir Open Source im Bacardi-Projekt verwenden. Ich gebe euch mal einen kleinen Überblick, was wir jetzt machen. Also machen einmal kurze Vorstellungen, wer wir überhaupt sind. Dann reden wir ein bisschen über
Raumfahrt-Rückstände, dann über unsere Software an sich und dann über Open Source im Bacardi-Projekt. Und anschließend eine Open Source-Software, die wir in diesem Kontext entwickelt haben, F2X, das übernimmt dann den Michael. Ja, wir sind von der Einrichtung Simulations- und Softwaretechnik vom Deutschen Zentrum für Luft- und Raumfahrt.
Wir sind eine Einrichtung für Softwareforschung und Research Software Engineering bzw. wissenschaftliches Rechnen, das sind verschiedene Unterabteilungen. Der Michael hat das sehr schön ausführlich in seinem Talk vorher dargestellt, wer das noch mal sehen möchte, kann da noch mal genauer reinschauen. Genau, wir sind im Moment ungefähr 70 Mitarbeiter an fünf verschiedenen Standorten, die wir hier sehen.
Das ist dann Berlin, Braunschweig, Köln und Oberpfaffenhofen. In dem Projekt, was ich euch gleich vorstelle, sitzen wir hauptsächlich in Berlin, Köln und auch Oberpfaffenhofen. Genau, wer sind wir?
Ja, ich bin Michael. Ein paar habe ich vorhin schon mal gesehen. Ich bin Softwareentwickler bei SC, Python-Enthusiast und so ein bisschen auch bei uns die professionelle Rubber Duck. Das heißt, ich werde öfter mal angerufen, wenn Leute mir ihre Software erklären wollen, damit sie weiterkommen. Ja, ich bin seit 2004, also 15 Jahren, zwischen am DLR und habe schon eine
ganze Menge Softwareentwicklung, alles querbiet durchgemacht, was wir da an Software im DLR so entwickeln. Macht mir auch viel Spaß, da Support und Consulting und Trainings zu geben. Genau, ich bin Eifriger Nutzer von der professionellen Rubber Duck hier, von dem Michael. Wir rufen uns häufig an und reden miteinander über Software, was immer sehr hilfreich ist.
Genau, ansonsten bin ich aber eigentlich wissenschaftlicher Mitarbeiter und mache auch Forschung am DLR im Bereich Software Engineering und Software Analytics. Ich bin seit 2016 am DLR, habe meine Masterarbeit am DLR geschrieben und seit 2017 halt fest dort angestellt. Genau, ansonsten bin ich ambitionierter KSP Pilot. Ich versuche es halt. Wer das nicht kennt, Curve of Space Programm, wunderschönes Programm.
Kann man sich auch viel hier anschauen, was hier den Hintergrund hat. Genau, und spiele in meiner Freizeit im POC mit. Das kann man hier kaum sehen, aber ich wollte es nicht so groß machen, das ist noch nicht so wichtig. Okay, reden wir ein bisschen über Raumfahrtrückstände und generell über Space Debris, wie man so schön sagt.
Ja, Space Debris, wie kann man das einordnen? Es gibt in der Wissenschaft die sogenannte Space City National Awareness, die SSA. Das ist im Prinzip so die große Community, die sich damit beschäftigt. Die unterteilt sich in drei wesentliche Bereiche. Das sind einmal die Near Earth Objects, das ist das, was man immer in der Presse hört.
So, morgen kommt wieder was Großes. Ich glaube, war das vorgestern? Ich weiß es nicht, vorgestern war wieder irgendwie was unglaublich nahe, nämlich irgendwie siebenmal ein Mondabstand an uns vorbeigeflogen ist. Genau, das sind die Kollegen, die beschäftigen sich im Prinzip mit Objekten, die einen Sonnenorbit haben, die aber unsere Erdbahn kreuzen.
Anderer Teil ist Space Weather. Die beschäftigen sich mit Solar Flares, magnetischen Stürmen auf der Sonne, alles, was auch irgendwie unsere Technik beeinflusst, wie zum Beispiel Satelliten. Und dann gibt es noch das SST, Space Surveillance and Tracking. Das ist im Prinzip das, wo wir arbeiten in dem Bereich. Da geht es im Prinzip um
man-made objects, also um das, was wir selber da oben platziert haben und wie man das erfasst, tracked und eben auch irgendwo berechnet herausfindet und auch schaut, was man damit macht. Das gibt viele Aspekte in dem Bereich und es gibt auch hier viele Überschneidungen zwischen diesen Bereichen.
Schauen wir uns mal diesen SST-Bereich an und insbesondere Raumfahrtrückstände. Das sind relativ aktuelle Zahlen von der ESA, von deren Webseite. Die Quelle ist hier unten. Was gibt es im Moment? Wir hatten seit 1975 so 8.950 Satellitenstarts. Genau weiß man das halt einfach nicht.
3.950 ungefähr sind definitiv wieder eingetreten seit dem Zeitraum. Man schätzt, 1.950 sind aktiv. Das weiß man auch nicht so ganz genau, weil es gibt dort oben Satelliten, die irgendwie nichts tun und manchmal dann doch wieder. Und dann gibt es halt ungefähr 3.500, die definitiv defekt sind, ausrangiert, die
halt einfach da oben in irgendeinem Friedhofsorbit oder auch in ihrem eigentlichen Orbit rumschweben, ständig ihre Bahn verändern durch Space Weather tatsächlich. Genau. Dummerweise gab es seit 1975 so 500 Vorfälle mit diesen defekten Teilen und auch mit aktiven Teilen.
Das heißt, es gab Kollisionen mit Satelliten untereinander. Es gibt Explosionen von Oberstufen, weil dort Resttreibstoffe drin sind. Und das korridiert die Metalle und die extremen Hitzeunterschiede bei Tag- und Nachtzyklen, wenn der Satellit um die Erde kreist, sorgt halt irgendwann dafür, dass es Risse gibt und dann explodiert halt einfach der Restwasserstoff zum Beispiel, der noch da drin ist. Und dann sorgt das auch wieder für Schrott.
Ja, und dann gibt es halt noch so die Vorfälle menschlicher Art, so wir müssen einmal zeigen, dass wir Satelliten abschießen können. Auch das gibt es. Ich glaube, Indien war letztes Mal in der Presse damit. Ja, was schätzt die ESA in ihren statistischen Modellen, muss man dazu sagen?
Es gibt so 34.000 Objekte größer als 10 cm, vermutlich. Zwischen 1 und 10 cm vermutet man so 900.000. Und zwischen 1 mm und so kleiner 1 cm sind es dann so 128 Millionen Teile. Was heißt das? Ja, wenn man auf die rechte Seite guckt, das ist so eine 8 cm dicke Aluminiumplatte.
Und die kleine Kugel ist so 12 mm groß. Und die hat man mit 7 km pro Sekunde mal da drauf geschossen. Das ist der Effekt, den man davon sieht. Also das schmilzt halt regelrecht weg. Man sollte allerdings bedenken, im Zweifelsfall treffen Objekte im Orbit genau aufeinander zu.
Das heißt, es sind dann 14 km pro Sekunde. Das hat dann nochmal andere Auswirkungen. Ja, nochmal einen kleinen Überblick zu geben. Das ist jetzt aus unserem Projekt so ein bisschen so unsere Visualisierung, womit wir schauen können, wie denn unsere Orbitbahnen berechnet werden. Ich glaube, man kann es jetzt nicht so schön sehen aufgrund der Auflösung, aber es gibt dort unglaublich viele rote Punkte.
Irgendwo ist da auch die ISS-Bahn, die man kaum erkennt, eingezeichnet. Und diese roten Punkte, das ist alles Weltraumschrott katalogisiert. Und diese roten Punkte im nahen Erdorbit hier sind 60 % von einem einzigen Zwischenfall. 60 % des Schrott sind zwei Satelliten, die sind mal kollidiert. Und jetzt sieht es so aus.
Wichtig, die Punkte sind nicht richtig skaliert. Also so groß, wie die jetzt da sind, sind die natürlich nicht. Da ist doch noch Platz zwischen. Gut, das mal so als Einführung. Warum brauchen wir sowas wie Bacardi?
Beziehungsweise, was ist Bacardi? Oder was soll es werden? Bacardi ist im Prinzip eine Datenbank zur Speicherung und Verarbeitung von genau diesen Daten über Weltraumschrott. Es geht darum, eine Bahndatenbank aufzubauen, die möglichst vollständig und auch sehr genau ist.
Und die soll im Ende den Missionsbetrieb vom GSOC, also dem Deutschen Raumfahrtkontrollzentrum, der Deutsche Name, in Oberpfaffenhofen unterstützen und dort zum Beispiel da Kollisionswarnungen machen, für deren Satelliten, die sie dort betreiben.
Gut, genau. Und es geht dann halt um unabhängige Warnbestimmung auch aus eigenen Sensordaten. Das heißt, es wird dort auch in diesem Projekt noch ein eigenes Sensornetzwerk aufgebaut, das wir dann wieder benutzen, um weitere oder genaue Orbits zu berechnen. Was machen wir von SC oder wo helfen wir? Eben bei den Algorithmen und bei der Optimierung der Software.
Es ist halt ein nicht triviales Problem, Vergleiche und Kollisionen zu errechnen von vielen Hunderttausend Objekten. Dafür braucht man durchaus Spezialsoftware, aber auch Hardware. Genau, nochmal als generellen Systemüberblick von Bacardi. Also was machen wir? Wir haben ein Sensornetzwerk mit verschiedenen Arten von Sensoren.
Trackingradar, Überwachungsradar, Lasertracking, raumgestützte Erfassung von SpaceDV. Es gibt auch Satelliten, die tatsächlich nach Schrott suchen. Und optische Teleskope. Optische Teleskope ist dann auch dieses SmartNet, das kann man in dem Paper dazu dann nachher sehen,
was wir hauptsächlich im Moment als Input benutzen. Was brauchen wir noch, um Bahndaten und Sensordaten zu verarbeiten oder zu Orbits umzurechnen? Wir brauchen Bahninformationen initial, also wir brauchen Informationen über Objekte, die es schon gibt. Wir brauchen deren Eigenschaften, sowas wie Masse, Oberfläche, weil das hat alles Einfluss auf die Bahn,
wenn sie dann durch andere Parameter beeinflusst werden, zum Beispiel Drag durch die Atmosphäre, wenn sie sehr tief drin sind. Und natürlich brauchen wir von den Kollegen vom Space Weather solche Informationen wie Sonnenaktivität,
weil auch die magnetische Strahlung und sowas hat Einfluss darauf, wie Objekte sich bewegen. Genau, wenn wir unsere Bahn berechnet haben mit unseren Prozessoren auf der rechten Seite, können wir halt diese Tracks, die neu berechneten Orbits an unsere Nutzer rausgeben über verschiedene Schnittstellen, zum Beispiel REST APIs.
Oder auch wieder zurückführen in die Teleskope, um sie anzuweisen, dass sie doch nochmal mehr Daten sammeln sollen von bestimmten Objekten, weil wir da noch nicht genug haben zum Beispiel. Noch einmal eine schematische Systemarchitektur, wie wir das jetzt aufgebaut haben, eher in einer Komponentendarstellung. Wir haben ein Django auf der rechten Seite, das ist sozusagen unsere Kernkomponente,
die modelliert halt die Daten. Damit werden die Daten modelliert und dort sind auch die Algorithmen abgelegt in dieser Komponente, die dann direkt auf die Datenbank zugreifen, um entsprechend neue Daten zu generieren. Und auf der linken Seite haben wir einen Prozess Scheduler, also ein System,
das in regelmäßigen Abständen weitere Informationen abruft von externen Systemen und aber auch die Berechnungen startet. Und dazu nutzt es dann die Algorithmen, die in der rechten Komponente definiert sind. Da haben wir uns klar dafür entschieden, das an der Stelle zu trennen,
weil es durchaus sein kann, dass man zum Beispiel mal diese Komponente oder das System auf der linken Seite austauschen möchte. So verlieren wir nicht diese ganze Logik der Algorithmen, weil das ja durchaus sehr kompliziert zu implementieren ist. Das heißt links ist wirklich nur ein Scheduler. Ja, so viel zu dem Hintergrund von Bacardi.
Was nutzen wir jetzt für Open Source? Ich habe natürlich jetzt gerade schon ein bisschen gespoilert, Django und Airflow. Aber warum machen wir das? Zum einen, Open Source ist offen verfügbar, wir können uns den Code anschauen, wir können ihn bewerten, wir können nötige Features hinzufügen,
wenn da Features fehlen, die wir eben nicht haben. Oder wenn man spezielle Anforderungen in einem Projekt hat, ist es halt auch meistens gar nicht möglich, Software einzukaufen in diesem Bereich zum Beispiel. Das ist halt auch schlicht zu teuer, weil man Ressourcenknappheit in wissenschaftlichen Projekten durchaus kennt. Und genau das sind so die letzten beiden Punkte,
die wir auch wirklich, was uns antreibt, auch Open Source Software zu benutzen. Allerdings sollte man darauf achten, wenn man Open Source Software einsetzt, dass man sich diese Software genau vorher anschaut. Also dass diese Open Source Software nachhaltig ist,
dass man sie auch länger benutzen kann, langfristig benutzen kann. Dass sie einen Funktionsumfang hat, der einen möglichst gut unterstützt, dass sie stabile Schnittstellen bietet, soll heißen, das nächste Release kommt raus und die Software funktioniert nicht mehr, weil alle Schnittstellen geändert wurden und sei es nur eine API. Dass sie benutzbar ist, auch vom Anwender, dass sie nicht irgendwie nur von Technikern zu bedienen ist beispielsweise.
Genau, dass die Dokumentation entsprechende Qualität und Umfang hat, dass auch das Projekt aktiv ist, also eine Open Source Software zu benutzen, die nicht mehr aktualisiert wird, bringt einem keine Vorteile. Genau, und dann gibt es halt noch speziellere Probleme, nämlich die verwendeten Lizenzen. Kann ich diese Software überhaupt in meinem Projekt einsetzen?
Und wie sind auch die Softwareabhängigkeiten und auch die Lizenzabhängigkeiten von der Software, die in dieser Software enthalten sind? Es gibt halt Open Source Projekte, die nicht darauf achten und das kann echt problematisch sein, wenn ich halt, zwar eine Software habe, die als Apache 2 lizenziert ist,
aber da unten drunter irgendwie eine Software läuft, die GPL benutzt. Eigentlich müssten die ihre Lizenz ändern und das wird auch wieder Auswirkungen auf Mein Code haben. Auf sowas muss man explizit vorher achten. Gerade dann, wenn man mit dem Gedanken spielt, seine Software vielleicht auch mal selber zu veröffentlichen.
So, ich gebe jetzt noch einen kurzen Einblick in Django. Was ist Django? Django ist eigentlich ein Python Framework zur Erstellung von Webseiten. Hat aber den großen Vorteil, dass es einen Object Relational Mapper bietet. Und damit kann man wunderbar Datenbanken modellieren und zwar zum sehr großen Teil unabhängig davon, welches Datenbanksystem man benutzt, solange es relationell ist.
Und das halt in Python abbildbar ist in Objekten. Also man modelliert seine Datenbanken im Prinzip über Python-Objekte. Es hat eine BSD-Lizenz, damit können wir das ohne Probleme einsetzen. Hat wirklich eine große Community, große Konferenzen. Es gibt unglaublich viel Material zu Django.
Und es hat auch feste Feature-Releases alle acht Monate. Das hat Patch-Releases und das hat Long-Term-Support. Das kann manchmal echt nützlich sein, wenn es darum geht, dass man seine Software in anderen Stellen erweitern muss und eben gerade keine Zeit hat, irgendwie das neueste Release von Django mit einzubauen. Das sind wichtige Aspekte, die man immer im Hinterkopf haben sollte.
Wo setzen wir Django ein? Man hat es vielleicht auf der Systemarchitektur gerade gesehen. Primär zur Definition des Datenbankmodells. Was wir auch sehr nutzen, ist das Migrations-Konzept von Django. Da kann man für jede Änderung an der Datenbank Migrations erzeugen,
die die Änderungen abbilden, die dann später in der Datenbank landen sollen. Und das hilft einem beim Release. Und es hilft einem vor allem auch später zu verfolgen, wenn etwas kaputt geht, welcher Datenbank-Eintrag oder Eintrag, welche Tabelle hat sich geändert. Das wirkt halt dem entgegen, dass unsere Datenbank kaputt geht, weil mit tausenden Objekten drin können wir uns das einfach nicht leisten.
Und wir entwickeln halt dedizierte Apps. Das ist ein Konzept in Django. Man kann halt verschiedene Apps in einem Projekt für verschiedene spezielle Dinge machen. Das wäre bei uns zum Beispiel eine Administration- und Monitoring-App und eben eine dedizierte Rest-API, die wir an- und abschalten können, je nach Bedarf, um eben Daten direkt aus der Datenbank abzurufen, wenn man wirklich nur Daten braucht.
Das zweite Projekt, das wir relativ neu eingeführt haben, ist Airflow. Da sage ich vielleicht mal ein bisschen mehr zu. Das ist ein Framework zur Prozessautomatisierung. Das gibt es erst seit 2014 und aus 2015 ist es erst open source. Apache-2-Lizenz und Mitglied bei dem Incubator-Programm.
Ist also noch relativ jung, die Software, und hat eine relativ kleine Community. Hinsichtlich der Integration im Bacardi ist da schon ein bisschen Risiko, dieses Projekt zu integrieren, das kann man nicht anders sagen. Man weiß halt nicht, wo sich das hin entwickelt. Es kann auch sein, dass sich die Entwicklung stagniert. Momentan haben sie also ungefähr halbjährliche Releases und aber unregelmäßige Patch-Releases.
Insbesondere die APIs ändern sich immer wieder ein bisschen. Das ist nicht zu vernachlässigen, wie wir gemerkt haben. Das hatte ich gerade schon erwähnt. Man muss dann viel Arbeit da reinstecken. Wenn man eine neue Funktion haben will, muss man plötzlich doch wieder irgendwas anfassen.
Die Dokumentation leidet natürlich unter diesen API-Änderungen auch. Dann versucht man irgendwas zu nutzen von einem neuen Feature. Das funktioniert einfach deswegen nicht, weil die Dokumentation nicht stimmt. Man versucht und versucht und versucht und irgendwann findet man heraus, das war jetzt alles umsonst. Wie gesagt, wo nutzen wir es?
Früher hatte Bacardi einfach Skripte. Die wurden aufgerufen auf diesen Prozessoren. Das waren Cron-Jobs im Endeffekt. Das hat auch funktioniert, aber es ist einfach nicht nachhaltig. Vor allem kann es eins nicht, nämlich skalieren. Wir haben das Problem, dass wir mit immer mehr Sensoren, immer mehr Daten verarbeiten müssen.
Irgendwann reicht eine Maschine nicht mehr aus. Das heißt, wir müssen in der Lage sein, Prozesse auszulagern auf andere Maschinen. Zum Beispiel, um Korrelationen auf GPUs zu rechnen. Das machen wir eben genau mit Airflow. Das ist nämlich in der Lage, diese Ausführungseinheit auszutauschen durch zum Beispiel Celery, falls das ein Begriff ist.
Das macht Messaging im Endeffekt über einen Broker. Dann kann man die Prozesse auf beliebigen Rechnern ausführen. Man hat aber immer noch das gleiche System. Das heißt, wir tauschen einfach den Exegutor, den sogenannten aus und sind in dem Moment sofort in der Lage, horizontal zu skalieren. Nur mal so als kleinen Einblick.
Das Schöne ist, mittlerweile ist es so, dass wir sogar unsere eigene Open Source Software aus diesem Kontext heraus veröffentlichen. Und die hat der Michael zum Großteil geschrieben. Deswegen erzählt er euch dazu was. Und jetzt kommt der richtige technische Teil. Ich gebe mir, dass es nicht zu technisch wird. Ich möchte jetzt kurz ein bisschen was über F2X erzählen.
Wer hier kennt F2Pi? Schon mal gehört? Okay, gut, dann hole ich ein bisschen aus. Wir haben in unserem Projekt Fortran kurz. Diese ganze Bahnberechnung, die läuft in Fortran. Und wir haben aber jetzt gesehen, unsere ganze restliche Software ist in Python geschrieben. Und da muss man die beiden Software zusammenbringen. Sprich, wir müssen irgendwie den Fortran-Code aus Python aufrufen.
Und da gibt es eigentlich die Standardlösung F2Pi. Die man da, weil das ist keine unübliche Aufgabe in der Wissenschaft, Fortran-Codes von Python aufzurufen und dann F2Pi daher. Haben wir auch versucht. Das ist halt wirklich quasi Standardlösung. Die ist eigentlich auf jedem wissenschaftlichen Rechner installiert. Ist seit Jahren stabil.
Obwohl es auch heißt, seit Jahren kaum Updates. Ist hochautomatisiert. Das heißt, man kann da wirklich seinen Fortran-Code reingeben. Und hinterher hat man ein fertiges Python-Modul, das man aufrufen kann. Und ist halt wirklich einfach zu benutzen für Leute, die halt nicht Softwareentwickler sind wie ich. Das ist auch ein ganz wichtiger Faktor dabei.
Das Problem ist, dass der Funktionsumfang von F2Pi nur gewisse Datentypen zulässt. Wir brauchten mehr für unsere Bacardi-Software. Wir haben eine starke Abhängigkeit des generierten Codes, das ist das Tool für uns gebaut von dem Compiler, den wir hinterher absetzen. Vor allem habe ich versucht, das an unsere Bedürfnisse anzupassen. Und habe dann nach zwei Tagen aufgegeben,
versucht herauszufinden, wo ich da jetzt überhaupt ansetzen muss. Das ist ein bisschen schwierig. Gut, das ist jetzt nicht so schlimm, weil wir haben ja InnoPython, das wir anbinden wollen an Fortran. Aber das kann das auch nur. Mein Tool kann mehr. Kurz eine Übersicht. Was macht das?
Wir haben da oben einen Fortran-Quelcode, F90 source. Und noch eine kleine Konfigurationsdatei, die wir dazu packen können. Die wird vom Präprozessor eingeladen. Das ist eigentlich nur ein kleiner Vorschritt. Und hinterher letztendlich liest man in einem Parser diese Quelcode-Datei ein. Dann habe ich einen AGT, das ist quasi eine Abbildung von dem Quelcode als Baum.
Und den gebe ich dann in einen Generator, der liest sich ein Template ein und generiert daraus dann entsprechend weitere Quelcode-Dateien, die ich brauche, um den Fortran-Quelcode von Python aus aufzurufen. Der macht quasi die Übersetzungsschicht zwischen Python und Fortran. Genau. Das ist jetzt wahrscheinlich sehr technisch.
Ich habe das großen Zelt aus einem anderen Vortrag kopiert, den ich auf einer Python-Konferenz gehalten habe. Aber ich sehe es trotzdem ein bisschen. Was wichtig ist, im Gegensatz zu dem F2Py. F2Py versucht man, in regulären Ausdrücken zu raten, was da jetzt gerade vor sich hat. Ich lese wirklich den ganzen Fortran-Quelcode ein. Das heißt, ich versuche wirklich zu analysieren, was geht.
Das ist deutlich langsamer. Und auch das Programm, das ich da benutze, das ist PyPlus. Das ist eine Python-Bibliothek, mit der man Parser bauen kann. Die ist super schön, da kann man wirklich sehr komplexe Parser mitbauen. Ist nicht unbedingt schnell. Das ist aber auch nicht so schlimm für meinen Anwendungsfall. Aber inzwischen wird es leider nicht mehr weiterentwickelt. Und der Nachfolger, den der ursprüngliche Entwickler entwickelt hat,
der passt für meine Bedürfnisse überhaupt nicht. Was schön war, Open Source hat mir auch weitergeholfen. Fortran hat eine Grammatik, die muss man irgendwie eingeben. Da gab es zum Glück das Open-Fortran-Projekt, das ich nach einiger Zeit suchen gefunden habe. Da war so eine Grammatik fertig, die konnte ich einfach weiterverwenden. Da habe ich mir da auch eine ganze Menge Dank Open Source gespart.
Und dann musste ich eigentlich letztendlich nur diesen Umwandlung. Also dieser Parser, der gibt mir einen Baum, der ist sehr komplex. Da sind viele Informationen drin, die ich nicht brauche. Und da habe ich mir gedacht, okay, dann baue ich mir einen einfachen Baum davon, wo nur das drin ist, was ich brauche. Das habe ich dann AGT, oder Abstract Generation Tree genannt, im Gegensatz zu AST, was der Abstract Syntrax Tree ist. Und das Schöne dabei ist, ich habe nicht nur den Baum einfacher gemacht,
weniger Daten, die ich verarbeiten muss, sondern ich bin jetzt auch unabhängig von dem Parser, den ich vorne benutze. Das heißt, es ist zwar ärgerlich, dass PlayPlus jetzt nicht mehr funktioniert, aber ich bin relativ frei, was anderes zu benutzen an der Stelle. Genau. Wie gesagt, da habe ich jetzt auch andere Ansätze in Planung, wo man vielleicht als Studentenarbeit oder so etwas, man versuchen kann, den Parser auszutauschen.
Komme ich leider derzeit wenig zu. Genau. Und dann jetzt die andere Seite, das Spannende ist halt diese Code-Generierung. Das ist sogenannte Template-generierte basierte Code-Erzeugung. Eigentlich heutzutage, wenn man ein Modell hat, das heißt, irgendeine abstrakte Darstellung von irgendwas, und das in Text umwandeln will, zum Beispiel Quellcode, nimmt man sich ein Template, der aus dem Modell die Information rausholt.
Genau, oder wie es da technisch formuliert ist, die Transformation der Modellinstanz in Text mit Hilfe von Templates. Das heißt, ich gebe einem einmal das Modell, den AGT in meinem Fall, dann eine Modellinstanz, also nicht erstmal das Modell, das heißt, ich sage ihm, ich habe einen AGT, und dann gebe ich ihm einen, das ist mein konkreter AGT jetzt, und dann muss ich noch das Template eingeben,
und dann kommt am Ende Quellcode raus. Und das ist eigentlich auch relativ einfach, so dass jetzt die Entwicklung tatsächlich sich im Wesentlichen darauf beschränkt hat, diese Templates zu entwickeln. Das heißt, diese Templates, die diesen Code generieren. Das ist leider nicht einfach. Da steckt sehr viel Wissen drin. Man muss halt an der Stelle dann wirklich nicht nur wissen, wie kann ich jetzt ein Integer im Fortran-Code nach Pysen weitergeben,
sondern man muss dann an der Stelle auch noch wissen, wie funktioniert der Compiler da drunter. Also da war sehr viel Hirnschmalz drin. Aber das Schöne ist, dadurch, dass es Sprachen sind, kann ich das nicht nur nach Pysen anbinden, sondern ich habe auch mal probiert es nach C-Sharp und nach Java, und es geht alles relativ gut, wenn man sich ein bisschen mit dem Template-Programmi auskennt.
Genau. So konkret sieht es dann tatsächlich so aus. Ich habe unten meinen Fortran-Code. Das ist das Stückchen Code, das existiert, das ich ansprechen will. Darüber muss ich dann eine Schicht bauen, die von Fortran-Code ein C-Interface exportiert. Das ist leider irgendwie bis heute nicht anders zu machen als C-Interfaces, als Standard-Interfaces zu nehmen, weil alle anderen Programmiersprachen haben immer so etwas sehr
Compiler-spezifisches oder sehr Plattform-spezifisches, sodass man einen Fortran-Code und einen Go-Code zum Beispiel nicht ohne weiteres zusammenbauen kann, sondern man muss mal C-Layer bilden dazwischen. Da gibt es zum Glück seit 2005 Fortran-Features, dass man so etwas exportieren kann. Das benutze ich, und dann habe ich von Pysen aus noch einen Layer.
Das heißt, Pysen muss jetzt diesen C-Code aufrufen. Ich bin von Fortran nach C gekommen, jetzt muss ich von C nach Fortran nach Pysen. Und da gibt es auch ein Modul, das ist C-Types. Das macht das direkt zur Laufzeit, das ist sehr langsam. War aber jetzt erstmal die einfachste Option zu implementieren. Aber das Schöne ist, es sind ja Templates, das heißt, ich kann das auch irgendwann mal austauschen. Genau.
Es gibt ein paar verschiedene Templates, und aktuell ist es tatsächlich das Schöne, dass dieses Projekt im Einsatz ist. In unserem Bacardi-Projekt und noch zwei, drei anderen Projekten am G-Sock, und dadurch kriege ich halt auch wirklich wertvolles Feedback, weil es auch was die realen Anwendungsfelder sind, die abgedeckt werden müssen. Hier ist nochmal so ein Beispiel, wen das interessiert. Ich habe halt eine Fortran-Funktion, die soll irgendein Polinom, das ich über einen Grad
und die Koffizienten berechne, irgendwie berechnen, ist dann auch noch implementiert. Und auf Pysen-Seite ist das voll schön, weil ich kann sagen, ich habe ein Polinom, und jetzt evaluiere ich mir das Polinom, und ich kann wirklich eins zu eins die Fortran-Funktion von Pysen aus aufrufen, ohne dass ich mich darum kümmern muss, wie das übersetzt wird.
Jetzt endlich, wie gesagt, haben wir das initialen Bacardi entwickelt, weil das F2Pi nicht funktioniert hat. Und Ziel war halt wirklich diese Fortran-Bibliothek, die bei dem Raumfahrt-Kontrollzentrum existiert, um Pysen auszunutzen. Aber dadurch schatze ich jetzt auch inzwischen eine rege Nutzung dieses Codes oder des Tools F2X am Raumfahrt-Kontrollzentrum entwickelt.
Es gibt jetzt verschiedene Nutzer, die diese Fortran-Bibliotheken benutzen wollen. Die bauen alle sich unterschiedliche Interfaces. Und das ist ganz spannend, weil ich da von vier, fünf Projekten inzwischen Rückmeldungen kriege. Ursprünglich hatte ich zwar auch noch einen Plan, andere Sprachen zu supporten, aber das haben wir jetzt erstmal sein gelassen. Es ist genug Aufwand, das für eine Sprache zu machen.
Aber das Schöne ist, wenn man es in Pysen hat, kann man es dann über irgendwelche Web-Schnittstellen ganz einfach bereitstellen. Und dann haben wir jetzt irgendwie einen Haufen Microservices am Raumfahrt-Kontrollzentrum, die sich gegenseitig unterhalten. Ist auch nicht mein idealer Umsatz, aber gut, funktioniert erst mal. Es ist schön, dass sowas auch funktioniert. Also wie gesagt, ich hatte super Tester,
die mir richtig viel Feedback geben, wo ich richtig viel dankbar bin. Und inzwischen habe ich auch Kontributoren. Jetzt habe ich hier mal so ein bisschen gegenübergestellt. Ich habe ja gesagt, C-Types ist langsam. Wenn man diesen Übersetzungslehrer sieht, da sieht man jetzt hier mal, ich habe das gleiche Programm mit F2Py, also einem Klassiker, übersetzt. Dann einmal mit F2X in C-Types. Das sind immer die ganz langen Balken.
Und dann habe ich aber mal angefangen, ein anderes Template, Cysen. Da kann man auch von C aus Pysen-Code integrieren. Und das ist dann tatsächlich eigentlich auf der gleichen Geschwindigkeit wie F2Py. Das heißt, ich habe jetzt auf jeden Fall auch ein gutes Argument, mich an diesen neuen Tablets ranzumachen. Oder irgendwer anders, der Spaß hat.
Genau. Und was halt auch sehr schön ist, ist dadurch, dass ich es open source gestellt habe, auf zwei, drei Konferenzen vorgestellt habe, habe ich auch Nutzer, die ich vorher noch gar nicht kannte. Das heißt, zum einen habe ich in den USA, am Los Alamos jemand, der rief, nee, der schrieb mir eine E-Mail, ich habe hier das mal ausprobiert, da ist ein Fehler in deiner Doku, kannst du mal korrigieren. Ansonsten sieht das ja spannend aus.
Und mit ihm habe ich irgendwie so einen monatlichen Rhythmuskontakt. Super schön. Dann habe ich auch auf einer Konferenz Entwickler von Leuten kennengelernt, die machen genau das Gegenteil von dem, was ich mache. Die haben Python-Code und kompilieren den nach Fortran. Um den zu beschleunigen. Auch sehr spannend. Hätte ich nie gedacht, dass man da so weit kommt. Aber die haben natürlich auch dieses Problem,
dann wieder die Übersetzung zwischen Python und Fortran hinzukriegen, wenn man dann den Fortran-Code von Python ausrufen will. Und mit denen will ich mich vielleicht auch gucken, dass wir da die Kräfte kombinieren können. Und dann finde ich ganz schön, dass auch Mike Müller von der Python-Akademie schon Interesse gezeigt hat. Da muss ich zwar noch ein bisschen
nacharbeiten und aufräumen, ein bisschen mehr Features einbauen. Aber auch das ist natürlich schön, so was zu hören, dass da Interesse besteht. Genau. Im Moment ist es so, dass es unter einer Apache 2.0 Lizenz verfügbar ist. War für mich eigentlich von Anfang an klar, dass ich das open sourcen will. Im GitHub, auf unserer Seite. Und der stützt schon echt viel Fortran. Inzwischen ist
Compiler unabhängig und ist auch inzwischen recht gut automatisiert. Das heißt, man kann da auch wirklich ganz einfach mal anfangen, um drum zu experimentieren. Das ist wie gesagt noch das langsame C-Types-Template. Aber, okay. Viele Verbesserungen habe ich im Plan. Das ist die Liste eigentlich noch viel länger. Aber mal gucken, wie weit ich da weiterkomme.
Genau. Also wie gesagt, so ein paar Template-Erweiterungen. Und auch die Benutzung der Oberfläche des Command Line Interfaces will ich verbessern. Und ich freue mich, wenn Studenten oder was sich melden würden. Ich habe leider nicht so richtig Budget für Mitarbeiter. Genau. Das war jetzt mein Ausflug für F2X. Schlafen noch nicht alle wirklich froh. Dann darf ich
jetzt auch noch die Zusammenfassung machen. Genau. Also wir haben gelernt, ganz am Anfang, wir haben tatsächlich uns das Problem der Raumfahrtrückstände gemacht. Die haben wir selber verursacht. Und die sind tatsächlich heutzutage ein Problem. Und auch Raumfahrt ist wichtig heutzutage. Das hätten wir vielleicht nur sagen müssen. Da kommt man nicht drum herum, leider.
Genau. Und diese Raumfahrtrückstände sind jetzt unsere Schuld. Unsere technische Schuld in gewisser Weise. Und wir müssen die beobachten. Wir brauchen dafür spezielle Software. Und dafür haben wir Bacardi entwickelt. Das steht übrigens für Backend Catalog for Relational Debrary Information. Falls die Frage auftaucht. Und das Akunym wurde gewählt, weil wir haben am Raumfahrtkontrollzentrum schon einen
Collision Avoidance System. Das kurz genannt Cola heißt. Und das Beste, was man in die Cola reinkippen kann, ist halt der Bacardi. Wenn man dann die Bacardi Software enthält, dann kriegt man das beste Ergebnis. Genau. Die Entwicklung von der Bacardi Software hat uns durch Open Source wurde uns sehr erleichtert. Also wir sind große Fans von der Nutzung von Open Source. Wir wissen leider nicht,
ob wir viel von Bacardi Open Source stellen dürfen, weil da halt doch Dual Use Informationen drin sein könnten. Aber wenn man Open Source Software verwendet, gerade in der Wissenschaft, hat man trotzdem drauf achten, dass man nachhaltige Software aussucht, weil es bringt einmal nichts, wenn, wie Martin erzählt hat, alle drei Monate die AP sich ändert und man einmal durch seinen kompletten Code durchgehen muss oder
wenn dann das Projekt irgendwie seit vier Jahren nicht mehr weiterentwickelt wird, kann man sich überlegen, das zu übernehmen oder, ja, das andere und Open Source ist halt auch nicht immer der Universalhammer, deswegen haben wir halt F2X entwickelt, damit es jetzt doch wieder der Universalhammer ist. Und jetzt haben wir noch, genau, einen Dank an mein ganzes Team oder an unser ganzes
Team, das ist die Crew, die an Bacardi zusammenarbeitet und jetzt haben wir auch noch Zeit für Fragen, denke ich. Vielen Dank. Ja, eine Frage.
Ist denn langfristig geplant, mal diesen Fortran-Code und das Ganze neu zu schreiben, dass man dann nicht die ganzen Übersetzungen braucht, also man kann schon nachvollziehen, dass man dann sagt, ja, das funktioniert, dann lassen wir es erst mal so, aber ist dann in 50 Jahren immer noch oder will man das mal angehen? Das wird sich nicht ändern, also das Problem bei diesem Fortran-Code ist,
also Fortran ist eine sehr lebendige Sprache, das darf man nicht unterschätzen, das wird weiterentwickelt, aber auch viel gelernt und gelernt, gerade im physikalischen Bereich zur Simulation, auch wenn es nur Richtung HPC geht, also von Fortran wird es ewig geben. Und die andere Sache ist, dieser Code ist tatsächlich, also vielleicht nicht ewig, aber Fortran wird uns noch eine ganze Weile begleiten und die andere Sache
ist, dieser Code ist halt wirklich, das ist der Schatz von Gesog sozusagen, das sind Routinen zur Berechnung von Weltraummechanik und Flugmechanik, das kann keiner so gut wie die. Und diesen Code neu zu schreiben, wäre zum einen ein Monsterprojekt, das Wissen ist gar nicht mehr da und dann ist halt auch das Problem dieses Softwares abgenommen
und Abnahme in der Raumfahrt heißt noch was anderes als ein paar Unitests durchlaufen zu lassen und jede kleine Änderung an dieser Software ist fast unmöglich, sonst hätte ich von Anfang an gesagt, pass mal die Interfaces an, dass wir die einfach nutzen können, aber das ist nicht. Das war von Anfang an gesagt, nee, die Software wird nicht angefasst, die wird nur benutzt. Man muss halt auch bedenken, was für Auswirkungen Fehler in genau diesem Fortran Code haben,
der wird halt wirklich benutzt, um aktiv auszurechnen, ob irgendwelche Objekte kollidieren. Dazu zählt auch das Columbus-Modul auf der ISS und die können sich das einfach nicht leisten, dass das fehlerhaft ist und wenn der Code seit 50 Jahren effizient funktioniert, ist das irgendwo auch ein Test und man kann das verstehen, dass das
nicht geändert werden soll. Dann kann ich gleich eine Frage anschließen. Gibt es da keine direkten Übersetzungsmöglichkeiten in einer anderen Sprache? Also gerade bei Fortran, ich bin wahrscheinlich der Älteste im Raum, als ich angefangen habe zu studieren, hieß es schon, Fortran machst du noch, aber ist eigentlich schon
vorbei. Das war in den 70ern und jetzt höre ich ja, es wird ewig leben, da hat man mir damals was Falsches erzählt. Das war damals vielleicht auch noch die Auffassung. Also ich hab als ich fertig war mit dem Studium auch gedacht, nee, Fortran wird es mir lange geben, aber das Gegenteil ist der Fall.
Fortran ist eine Programmiersprache, die unterstützt sowas wie HPC mit Direktiven. Man kann da wirklich sagen, okay, du paralysierst mir das jetzt auf fünf Parallelrechner, die mit einem Netzwerk verbunden sind. Fortran hat Direktiven, um auf GPUs zu rechnen und Beschleuniger zu rechnen und Fortran ist eine der ersten Programmiersprachen, die so eine Neuerung bekommt. Also da ist im Moment schon viel Wunsch hinter der Fortran-Community.
Und direkt Übersetzen in andere Sprachen, im Prinzip machen Compiler ja nichts anderes. Also die meisten haben dann eine Laufzeit-Bibliothek in diese Fortran-Konstrukte übersetzen, aber das so zu programmieren wie der Compiler, das schafft man von Benchair nicht, weil der halt gewisse Sachen automatisiert übersetzen und
optimieren kann, das geht mit anderen Programmiersprachen so nicht. Okay, also da bin ich zu weit weg von Fortran, aber interessant, wenn ich es gut, gibt es weitere Fragen oder sind jetzt alle schon nach dem Motto, gibt gleich Social Event, da stellen wir noch keine Fragen mehr.
Ja, aber scheint so zu sein. Ich danke noch mal für den Vortrag. Danke den Zuhörern fürs hier sein und wünsche noch einen schönen Abend. Ich glaube, es wird ganz gut. Das Wetter haben wir kurzfristig noch geändert. Es war ganz schön schwierig, aber es hat geklappt.