Lebensverlängernde Maßnahmen für Fortran-Codes
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 60 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: 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 | 10.5446/42471 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
6
13
21
25
41
53
00:00
CodeFORTRANDirection (geometry)Computer animation
00:19
WordPhysical quantityLecture/Conference
00:38
EnergieDigitizingSupercomputerVisualization (computer graphics)Software engineeringFORTRANWissenschaftlich-technische SoftwareCodeComputerComputerWordSoftwareVisualization (computer graphics)Systems <München>DigitizingRoute of administrationPositionSatelliteSoftware engineeringFORTRANEnergieGebiet <Mathematik>Password
03:27
CollisionPredictionInformationSoftware engineeringInternetdienstParticle detectorSatelliteMetreEstimationDatabaseBeobachter <Kybernetik>Spring (hydrology)Set (mathematics)CollisionState of matterProcess (computing)DatabasePhysical quantityLastteilungPredictionAverageSystems <München>SpeciesInternetdienstInformationSound effectChain ruleScope <Programmierung>MittelungsverfahrenComputer animation
10:30
FORTRANComputerCompilerCodeSoftwareWissenschaftlich-technische SoftwareFocus (optics)FORTRANFORTRAN-CompilerVersion <Informatik>Set (mathematics)SoftwareCodeComputer scienceSmart cardExpert systemForceMoment (mathematics)CompilerSockel <Mathematik>Computer programmingBeer steinMathematicianPhysical quantityBerechnungC-CompilerMetreProgramming languageFocus (optics)Computer animation
15:59
FORTRANCodeOpen sourceApache <Programm>Bindung <Stochastik>Field extensionTemplate (C++)Common Language InfrastructureModularityChain ruleExpert systemParsingMusical ensembleFORTRANSpring (hydrology)Similarity (geometry)Field extensionPriorityHungarian Academy of SciencesPreprocessorScientific modellingContent (media)Version <Informatik>Moment (mathematics)Regular expressionOpen sourceTemplate (C++)CompilerCodeUsabilityData typeApache <Programm>Wrapper (data mining)Well-formed formulaParsingPrint <4->Kooperatives InformationssystemComputer animation
21:10
High availabilityDirection (geometry)VelocityPixelFORTRANComputer fileCodeComputer animationLecture/Conference
Transcript: German(auto-generated)
00:00
Vielen Dank, auch hallo von mir. Ja, ich habe jetzt hier so einen Vortrag. Da geht es tatsächlich um die Arbeit, die ich die letzten vier, fünf Jahre gemacht habe. Dass sich die in die Richtung entwickelt, wie es jetzt gleich sieht, war am Anfang nicht absehbar, da war jetzt nicht zu viel verraten.
00:22
Kurz erstmal ein paar Worte zum DLR. Wir sind Deutschland, ein sehr, sehr großes Forschungszentrum in Deutschland, wenn nicht sogar eines der größten, haben inzwischen 30 Standorte in ganz Deutschland verteilt und machen Forschung auf den Gebieten Luftfahrt, Raumfahrt, Energie.
00:44
Das sind unsere drei klassischen und Verkehr, das sind sogar die vier klassischen Neuerdings jetzt auch Digitalisierung, weil das ein Passwort ist, dass die Politiker haben wollen und Sicherheit, wobei auch nicht ganz klar ist, was Sicherheit bedeutet. Nicht mal dem Chef des Sicherheitsbereiches im DLR.
01:00
Es ist klar, ob das jetzt zivile Sicherheit oder Rüstung oder was auch immer genaues heißen soll. Aber auf jeden Fall sind unsere sechs großen Themen und da hat sicherlich viel mit Software zu tun. Ich persönlich arbeite jetzt in der Einrichtung Simulation Software Technik. Wir sind noch kein Institutwerden, aber hoffentlich bald eins. Wir haben Standorte in Köln, Braunschweig, seit diesem Jahr auch in Oberpfaffenhofen und in Bremen.
01:26
Dann gibt es den Nicht-Standort, wo zwar auch jetzt die Software-Engineering-Gruppe, sechs Leute arbeiten, in Berlin. Da bin ich auch platziert und inhaltlich machen wir High-Performance-Computing. Da haben wir eine Gruppe, die vor allem in Braunschweig sitzt.
01:41
In Köln sitzt die High-Performance-Computing, in Braunschweig sitzt die Embedded Systems. Die machen auch Software für Satelliten. Außerdem haben die noch Visualisierung bei sich. Dann ist meine Abteilung eigentlich die verteilte Systemgruppe oder die Abteilung für verteilte Systeme. Da sind wir mit unserer Software-Engineering-Gruppe aufgehangen. Mein Kollege Tobias Schlauch habt ihr ja schon kennengelernt.
02:02
Carina Haupt habt ihr heute wahrscheinlich auch schon gesehen. Das ist meine direkte Vorgesetzte und wir machen da so im DLR ein bisschen Software-Engineering. In dem Vortrag möchte ich jetzt ein bisschen über das Projekt Bacardi sprechen, in dem ich seit einiger Zeit arbeite. Da geht es um Weltraumschrott. Da erzähle ich kurz gleich noch was dazu.
02:22
Das andere Thema, womit ich mich beschäftige, ist Vortran. Oder wie ich hier geschrieben habe, die Buhme wie am Computer. Braucht man heute überhaupt noch Vortran? Warum sollte man sich damit beschäftigen? Dann das typische Spannungsfeld zwischen wissenschaftlicher Arbeit und guter Softwareentwicklung, auch mit dem habe ich zu tun. Es war zum Glück nicht so, dass ich industrialisierte Anwendungen fertig kriegen muss,
02:43
aber schon, dass die benutzt werden und Software-Engineering eher hinten angestellt wird. Genau, wie man dann mit sowas umgeht, wenn man Software tatsächlich während des Betriebs reparieren muss oder weiterentwickeln muss, das ist dann quasi so das große Challenge im Ganzen. Und dann noch einen kurzen Ausblick, wie es weitergeht.
03:02
Dann noch mal kurz zum Inhalt. Ich stelle hier gerade dieses Tool F2X. Da komme ich glaube ich nochmal davor. Aber allerdings diesmal nicht so, wie ich es das letzte Mal immer gemacht habe, technisch vorgestellt, was dieses Tool kann, sondern im Vortran wird es ja mal gleich. Aber diesmal möchte ich ein bisschen erzählen, wie ich überhaupt dazugekommen bin, überhaupt dieses Tool zu schreiben
03:22
und was da so meine täglichen Herausforderungen sind beim Softwareentwickeln. Aber zuerst mal das Projekt Bacardi. Da geht es, wie man sieht, um Weltraumschrott. Das hier ist zwar nicht alles Schrott, sondern auch einige Satelliten. Die sehen auch nicht alle wirklich so gleich aus.
03:40
Aber es ist ein schönes Bild, um zu sehen, okay, da schwirrt ganz schön viel um die Erde rum. Und diese Rückstände, diese sogenannten Raumfahrtrückstände, wie das offizielle Sprecht für Weltraumschrott ist, sind erst mal so nicht kooperative Objekte, die in irgendwelchen Erdorbits, größtenteils im niedrigen Erdorbit rumfliegen. Nicht kooperativ heißt also,
04:01
man kann die nicht mehr von der Erde aus anfunkten und steuern, dass wir dann kooperativ, das sind die Satelliten, sind diese kooperativen Objekte. Die müssen dann quasi den Weltraumschrottteilchen ausweichen. Und zu einer habe ich hier auch schon mal hingeschrieben, so eine magische Grenze sind zehn Zentimeter. Das ist so die Größe, bis zu der wir heutzutage die Weltraumschrottteilchen tracken können und tun.
04:22
Und dann kommt man schon auf so gut eine Viertelmillion an Teilchen, die da oben rumfliegen, die halt auch schon gefährlich werden. Hier sieht man mal, wie das so aussieht, dass es ein massiver Stahl, ein massiver Alublock, da ist eine kleine Stahlkugel draufgeschossen worden mit den 14 Metern pro Sekunde. Und da kann so ein kleines Teilchen schon
04:41
echt erhebliche Auswirkungen haben, wenn man denkt. Die ISS Außenwand ist vielleicht so dünn und da sind es Menschen drinnen, das ist schon alles gar nicht so einfach. Also diese Objekte sind ein Problem, auch schon ab drei Zentimeter. Und bei drei Zentimeter rechnen wir schon mit mindestens einer Million Objekte da oben. Das ist natürlich jetzt die große Frage,
05:00
wie kommen die da hin? Warum gibt es denn überhaupt so viele Raumfahrtrückstände? Die wichtigsten Quellen sind zum einen Satelliten, wo der Sprit ausgegangen ist, vorzeitig oder geplant oder auch Raketenoberstufen, die nicht wieder zurückgekommen sind. Die schwirren dann da oben rum und nach, je nachdem wie hoch die abklagen wurden, so nach drei bis 60 Jahren schlussen die wieder ab.
05:22
Und dann gibt es aber inzwischen auch tatsächlich eine ganze Menge großer Trümmerwolken. Die sind zum Beispiel entstanden als ausgebrannte Satelliten mit dem Rest Treibstoff explodiert sind oder dass halt auch Satelliten explodiert sind, weil sie von einer Rakete von der Erde getroffen wurden. Ich sage nur Antisatellitentests von China und Indien.
05:41
Es sind große Wolken. Es gab auch tatsächlich schon zweimal, dass Satelliten im Orbe zusammengestoßen sind und Trümmerwolken hinterlassen haben. Und da wurde halt immer mehr auch. Also die Prognose geht davon aus, also große Teile werden es eher weniger mehr werden, weil heutzutage, wenn man Satelliten hochschießt, hat man eine Strategie, wie man am Ende von dem Leben von Satelliten den auch wieder abstürzen lässt.
06:01
Aber diese Trümmer Teile werden immer mehr zum einen, weil halt so viel da rumschwürt, dass man gar nicht mehr alles beobachten kann, was miteinander kollidiert. Und zum anderen auch, ja, weil halt die coolen Staaten zeigen wollen, wie mächtig sie im Weltraum auch sind. Und es ist inzwischen zum Glück ein international wichtiges Thema. Es gibt Konferenzen und Meetings zum Thema
06:24
Raumfahrtrückstände, Weltraumschrott. Da geht es zum einen halt ums End-of-Life-Management, sprich, wie sorgen wir dafür, dass die Satelliten da oben nicht bis in alle Ewigkeiten weiter rumfliegen? Dann geht es auch darum, den Weltraumschrott zu beobachten, vorherzusagen. Das machen wir ganz viel mit unserem Bacardi-System.
06:42
Und das Problem ist tatsächlich, dass dieser Lawineffekt befürchtet wird. Und pessimistische Schätzungen davon ausgehen, dass, wenn wir so weitermachen wie jetzt, ist zwar die Erde in neun Jahren tot, aber in fünf Jahren können wir sie schon nicht mehr verlassen, weil da oben so eine dichte Schicht an Weltraumschrott rumfliegt, dass das zu viel wird. Genau.
07:01
Was ist jetzt Bacardi? Zunächst einmal, das ist der Backend Catalog for Relational Debrie Information. In der Wissenschaft, sicherlich bekannt, sucht man sich mal schöne Akronyme. Wir hatten schon das Collision Avoidance System von den Raumfahrtbetrieben, das hieß COLA. Da gibt sich Bacardi als natürlicher Partner ganz gut zu. So kamen wir zu dem Titel.
07:21
Aber ganz wichtig, offiziell sprechweise ist es kein Katalog. Wir entwickeln nur einen Demonstrator, den man als Katalog einsetzen könnte. Aber wir bauen keinen Katalog. Das ist ein politisches Thema, weil das Thema Weltraumlage ist hochoffiziell bei der Bundeswehr angehangen. Deswegen dürfen wir so was gar nicht offiziell machen. Deswegen dürfen wir auch offiziell keinen Katalog haben. Deswegen haben wir keinen Katalog,
07:41
sondern nur einen katalogartigen Demonstrator. Und den haben wir zusammen mit den Kollegen vom Deutschen Raumfahrtkontrollzentrum entwickelt. Das ist die German Space Operations Center. Die sitzen auch im DLR in Oberpfaffenhofen. Das ist das Projekt, wo ich vor fünf Jahren angefangen habe.
08:00
Damals hieß es so, wir haben hier eine Million Teilchen. Und da müssen wir jedes Teilchen gegen jeden alle sieben Minuten einmal durchgerechnet haben. Und ich dachte mir, okay, toughes Ding. Da muss man irgendwas gut Skalierbares bauen. Hab dann angefangen, ein bisschen Mittelwert zu beschreiben und so weiter. Und je mehr ich in das Thema eingestiegen bin, je mehr ich mit dem Projekt gearbeitet habe,
08:20
desto klarer wurde mir. Es ist gar nicht das, was wir brauchen. Also wir brauchen keine effiziente Mittelwehr, weil das Load Balancing ist eigentlich nicht so das Problem. Und auch das eine Millionen Teile gegen eine Million Teile müssen wir vielleicht in 60 Jahren mal irgendwann machen. Heutzutage ist das alles gar nicht. Aber genau, wichtig ist aber, wir wollen halt zum einen eine möglichst vollständige Bahndatenbank haben.
08:41
Das heißt, wir wollen sämtliche Daten bei uns haben, die irgendwo zu finden sind. Zum einen halt aus fremden Datenbanken importieren, zum anderen aber auch durch Beobachtung. Und wir wollen halt auch die Dienste, die am Raumfahrtkontrollzentrum laufen, zum Beispiel Kollisionswarnung, Manöver, Identifizierung und so was, wollen wir verbessern durch unsere besseren Daten.
09:00
Da ist dann hier so das letztendlich rausgekommen. Da bin ich jetzt schon gar nicht mehr so sehr beteiligt gewesen. Da war ich dann schon mit meinem eigenen Teil. Aber man sieht hier so, hier haben wir Airflow. Das ist ein Workflow Management System. Da kippen wir unsere einzelnen Prozesse rein, unsere Berechnungen, die wir machen müssen, zum Beispiel zwei Beobachtungen miteinander korrelieren
09:21
und daraus eine neue Bahn bestimmen oder so was. Genau, da haben wir Datenbanken, da wird das gescheduled und so weiter. Das ist der ausführende Teil. Dann haben wir Django. Da passiert unsere Datenhaltung im Wesentlichen drinnen. Da benutzen wir vor allem den ORM und ein bisschen auch Webinterfaces, Webstützstellen.
09:40
Und dann gibt es hier ganz wichtig die Flight Dynamic Libraries. Das ist das, was aus dem Raumfahrtkontrollzentrum kommt. Da haben sie nämlich eine umfangreiche Bibliothek mit sehr guten Flugdynamikcodes für Raumfahrzeuge. Und die sollten wir anbinden. Außerdem haben wir da noch zwei, drei andere Projekte
10:01
im Raumfahrtkontrollzentrum, mit denen wir sehr eng zusammenarbeiten. Das Smartnet versucht halt so ein weltweites Sensornetzwerk, also Teleskope aufzubauen, um halt Weltraumflot zu beobachten. Dann haben wir auch ein paar Leute, die lassen oben Satelliten rumfliegen und versuchen damit Schrotteile einzufangen und zu messen. Wir sind dadurch sehr schön eingebettet und können wirklich auch mit echten Daten arbeiten.
10:21
Andererseits haben wir natürlich dadurch auch mehr Projektpartner, die echte Daten haben wollen von uns. Das ist ein bisschen schwierig. Und on top kommt halt, dass diese Flight Dynamic Libraries, die sind alle natürlich komplett in Fortran geschrieben. Und die sind halt auch so gut, dass gesagt wurde, die müssen auch unverändert weiter benutzt werden.
10:42
Das heißt, wir dürfen da nichts dran ändern. So, und dann heißt es, okay, Fortran. Kann ich den Leuten in Fortran ausreden? Dann habe ich mal eine kurze Pro-Contra-Abschätzung gemacht. Braucht man überhaupt noch Fortran? Und Fortran hat schon ein paar Vorteile. Zum Beispiel ist es sehr lange bewährt. Die erste Version war Fortran 69 oder sowas, glaube ich. Und seitdem kommt einem schneller nach einem anderen.
11:02
Der letzte ist jetzt vor letztem Jahr, 2017, also das ist letztes Jahr rausgekommen. Das heißt, da wird auch tief weiter entwickelt. Ist ein richtiger Standard mit ISO-Nummer und allem drum und dran. Und für mathematische Probleme habe ich mir sagen lassen, ist diese Syntax auch sehr gut, sehr mathematikerfreundlich. Weil man zum Beispiel mit eins anfängt mit zählen und so eine Sachen.
11:22
Andererseits ist es natürlich auch ein neuer Gegenhalt. Es ist halt altbacken. Und es ist halt auch, ich habe da mal hingeschrieben, überarbeitet. Also es ist nicht, dass Fortran jetzt zu viel zu tun kriegt, sondern man kriegt richtig mit, okay, da hat man versucht, über die alte Syntax ein neues Konzept überzustülpen. Und wenn man versucht hat, mit Fortran objektorientiert zu programmieren,
11:40
merkt das. Muss man zum Glück auch nicht. Aber auch schon Speicherlöchungen und sowas. Hat einige Stellen, wo man sagt, okay, das ist jetzt nicht schön gelöst, aber ich verstehe warum. Gut. Noch ein Pro ist natürlich bei Fortran, man hat eine riesengroße Palette an verschiedenen Compilern, die auch alle mehr oder weniger standardkonform sich verhalten. Die sind sehr mächtig, weil Fortran-Compiler dürfen auch explizit eine ganze Menge machen,
12:03
was C-Compiler zum Beispiel nicht dürfen. Und auch wenn man noch neue Compiler entwickelt, so F-Längen, glaube ich, oder sowas heißt es, vom LLVM-Projekt. Die haben wir jetzt erst vor kurzem ihren Fortran-Compiler rausgebracht, damit auch eine aktuelle Compilerarchitektur zu unterstützen.
12:20
Andererseits kann man natürlich auch sagen, viele Compiler heißt auch viele inkompatible Versionen. Das heißt, man kann zum Beispiel einen interkompilierten Fortran-Code nicht mit einem GCC-komplizierten Fortran-Code gegeneinander linken oder auch zwei verschiedene GCC-Versionen von Fortran, die sind oder nicht mehr kompatibel und so. Da muss man tierisch aufpassen, dass man da alles richtig zusammen macht.
12:41
Und was halt wirklich tragisch ist, für Fortran gibt es fast gar kein SE-Tooling. Also man hat zwar GCC und die Compiler-Suiten, aber sowas wie eine statische Code-Analyse für Fortran oder sowas gibt es eigentlich nicht. So, aber dann gibt es halt noch das Totschlag-Argument, es gibt so viel existierenden Code, der muss weiterverwendet werden. Und wie gesagt, auch im Comfort-Kontrollzentrum heißt es,
13:02
okay, dieser Code ist so abgenommen und validiert, den dürfen wir gar nicht verändern, weil dann können wir nicht mehr sicherstellen, dass sie das Richtige berechnen. Haben sie dann auch 20 Meter noch Fehler drin gefunden, aber das ist ja ein anderes Thema. Aber wichtig, existierender Code, der darf nicht verändert werden. Und weil eigentlich keiner dieses System, was ich da gerade gesagt habe, im Fortran so entwickeln will,
13:21
haben wir gesagt, okay, wir brauchen mehr fachige Integration, ein Projekt, wo Fortran-Code bei uns mit Python zusammenkommt. Das ist ja, habe ich auch so einen Eindruck in der Wissenschaft, immer mehr der übliche Weg. Genau, das heißt, mit mehrsprachiger Integration habe ich mir gefragt, alles klar, endlich kannst du dich mal ein bisschen sinnvoll mit Fortran beschäftigen. Python kannst du ja sowieso schon, ist ja sowieso die beste Programmiersprache.
13:43
Jetzt versuchst du, das mal zusammenzuführen. Und ja, angefangen und wie vorhin schon kurz angedeutet, also Softwareentwicklung im DLR ist wissenschaftliche Softwareentwicklung. Das heißt, wir fangen an, haben irgendeine vage Idee und dann geht es dann am Ende zu great Software.
14:01
Zwischendurch haben wir halt diese use-as-you-write-Software, sage ich einfach mal dazu. Das heißt, die wird in dem Moment, wird gestartet. Oh, da ist noch ein Fehler. Schnell mal was fixen. Ich probiere hier mal kurz was aus, ob das vielleicht bessere Ergebnisse gibt. Mal was auskommentiert hier und da. Nur mal eben das Skript an die Daten angepasst.
14:22
Weil meine Daten jetzt nehmen wir ganz so, und so kennen wir alle, nehme ich an eine wissenschaftliche Softwareentwicklung. Leider das Übliche. Und wichtig halt auch, die Veröffentlichung, die ich am Ende schreiben will, ist das Arbeitsergebnis, dass das tatsächlich durch Software zum Einsatz kommt, ist sowas von egal. Diese Einstellung. Und dann kommt halt hinzu, dass die SE-Teams im DLR
14:40
auch trotzdem so eher ein bis drei Personen sind. Es gibt zwar ein paar große Projekte, warum man bei einem größeres Team sich um eine Software kümmert, aber wenn man zu dritt an einer Software sitzt, ist man da schon eher glücklich dran. Hinzu kommen dann noch Doktoranden oder auch, dass die drei Leute, die zusammen an der Software arbeiten, dann auch nicht parallel, sondern sequenziell zusammenarbeiten. Das heißt, einer zwei Jahre, dann der nächste zwei Jahre,
15:01
dann der nächste zwei Jahre. Und da ist dann natürlich, zum einen hat man dann keine SE-Experten, das sind die Domain-Experten, die da ihre Wissen kodieren, aber keine Leute, die Software entwickeln können. Und auch der Fokus auf Nachhaltigkeit ist halt nicht da. Also gerade, wenn man für seine Doktorarbeit irgendein Stück Software entwickelt.
15:20
Trotzdem kommt im DLR immer mal wieder so lange liebe Software zutage, die sich dann doch länger hält als nur bis zum Ende von der Doktorarbeit. Unter anderem halt auch dank der DLR-Software-Initiative, die ich hier nochmal explizit loben muss, wo unser Kollege auch sehr aktiv ist, haben wir es tatsächlich geschafft, auch in die Köpfe der Nicht-Informatiker,
15:41
immer mehr Informatik und Softwareentwicklung als wichtiges Thema reinzubringen, wird langsam besser. Deswegen kommen die Leute auch mehr zu uns, wir kriegen mehr zu tun. So gibt es dann halt auch diese Projektarbeit oder die Kooperation in diesem Bacardi-Projekt. Und kurz nochmal zusammenfassend, also die Weiternutzung der unveränderten Vortran-Codes
16:02
war oberste Priorität. Das heißt, da geht nichts drum, die müssen entwickelt werden, aber neue Entwicklungen wollten wir eigentlich in Python machen. Das heißt, wir haben jetzt dieses Gap zwischen Python und Vortran und jeder, der schon mal NumPy in der Hand hat. Ah, F2Py ist so die erste Idee, kam ja auch, ist ein etabliertes Tool, ist im NumPy mit drin, hat zwar nur einen eingeschränkten Sprach-Support,
16:22
aber okay, ich habe es trotzdem mal ausprobiert, geguckt, okay, so ein paar Sachen kann F2Py jetzt nicht. So an der einen oder anderen Stelle, wenn man zum Beispiel abgeleitete Datentypen übergeben will oder sowas, muss man gucken. Ging aber einigermaßen, habe ich mir dann angefangen, irgendwelche Wrapper zu schreiben,
16:41
weil ich habe erst den F2Py-Code selber erweitern wollen. Der PASA ist halt reguliere Ausdrücke und hatte ich nicht so richtig Lust, da mich weiter reinzuwühlen. Und auch die Code-Generierung, die ist ein bisschen sauberer, aber halt auch sehr compilerabhängig und alles mit sehr viel verschatteten Is-Elves und Prints.
17:01
Und ja, deswegen hätte ich gesagt, okay, F2Py erweitern, fixen ist nicht. Du musst trotzdem irgendwie diese erweiterten Sprach-Features kommen. Okay, dann machst du F2Py und schreibst dir halt nochmal einen Wrapper um den Fortran-Code, den du dann aufrufen kannst. Also die Idee, ja, da kann man dann zum Beispiel sagen, okay, das ist jetzt ein Speicherblock
17:21
von der und der Größe. Tu so als sei es ein Byte-Array, aber in Wirklichkeit ist es halt, hinterher wird es umgewandelt. Geht theoretisch in Fortran auch so ein bisschen, hat aber dazu geführt, dass ich dann doch recht umfangreiche Fortran-Interfaces schreiben musste, was mich dann dazu gefühlt hat, zu automatisieren.
17:41
Und wenn man dann so einen Wrapper automatisiert, dann geht es weiter, eins folgt dem nächsten. Und dann habe ich angefangen, okay, vielleicht noch C-Interfaces und P und da. Und letztendlich war ich dann irgendwann an der Stelle da, okay, jetzt machst du dein eigenes Ding. Also ich habe angefangen, Fortran-Kurze-Parse um Fortran-Interfaces zu generieren und sowas. Irgendwann waren eigentlich nicht alle Teile da und dann habe ich angefangen,
18:01
mein eigenes Wrapper-Tool zu schreiben. Da ist dann F2X entstanden und F2X hat so ein paar Sachen, ja, nutzt zur Interfacing zwischen Fortran und der C-Wild-SC-ISO-Binding-Standard, der von den meisten Compiler unterstützt wird, kann damit halt auch an andere Sprachen, die in C-Interfaces angebunden werden, weil es gibt ein sauberes C-Interface hinterher,
18:23
benutzt auf Parse-Seite keine regulären Ausdrücke, sondern eine richtige Fortran-Kramatik. Parse und Code Generator sind auch weitgehend entkoppelt und Code-Generierung kann ich dann auch nicht mit hard-gecodeten Strings, sondern mit Ginger-Templates gemacht, sodass man da auch relativ einfach Erweiterungen machen kann. Und das ist ein bisschen mehr State of the Art ist,
18:41
wie man heutzutage sowas umsetzen würde, steht als Open Source unter Apache 2.0, kann sich jeder benutzen. Und überhaupt sieht das jetzt so aus, da möchte ich jetzt auch gar nicht so viel drauf eingehen. Letztendlich haben wir einen Pre-Prozessor, Fortran kann man leider nicht ohne Pre-Processing parsen, das habe ich bisher noch keinen Compiler gesehen, der das geschafft hat.
19:00
Dann geht es durch einen Paser durch, da kommt ein AGT, das ist sowas wie ein Syntax-Tree, nur halt fürs Generieren, deswegen Abstract Generation Tree, habe ich den genannt, der wird dann ein Code-Generator und der nimmt sich dann die Templates und generiert den Code draus. Der sagt dann hier durch dieses Modell in der Mitte, kann man das schön entkoppeln. Kann man den Paser austauschen,
19:22
was ich schon ein, zwei Mal gemacht habe und den Generator theoretisch auch, beziehungsweise die Templates entsprechend anpassen. Genau. Und das ist eigentlich auch schon alles, was ich zu FGX noch kurz sagen wollte. Endlich habe ich jetzt in letzter Zeit tatsächlich auch sehr viel an der Usability von dem Tool gearbeitet.
19:41
Setup-Py-Integration auf Numpy-Basis, das heißt, man kann genauso schön mit F2X wie mit F2Py inzwischen rappen. Command-Zellen-Interface besser gemacht ein bisschen modularisiert und Dokumentation. Das waren alles so Ergebnisse, die sich daraus entwickelt haben, dass am Raumfahrt-Kontrollzentrum mit vier verschiedenen Versionen gearbeitet wird von F2X.
20:01
Und ich will weiterentwickeln, dass die auf die neuesten Versionen sind. Man muss es entsprechend so modularisieren, dass einzelne alte Module bei sich mit einhängen können. Hat aber ganz gut funktioniert. Am Anfang hatte ich ein bisschen dieses Gefühl Over-Engineering, aber inzwischen habe ich festgestellt, nee, war wichtig und gut so. Und demnächst kommen jetzt halt so noch Sachen. Ich will Templates neu machen, besser machen.
20:22
Im Moment benutze ich ISO-C-Bindings und C-Types für die Interfaces zwischen Python und Fortran. Ich will das eigentlich über ISO-C-Bindings und Cisen machen, um dann ein bisschen performanter zu sein. So eine Sache oder halt auch generell mal das, was ich jetzt in den letzten drei Jahren an F2X-Entwicklung gelernt habe, zu verbessern. Viel getestet werden darf noch.
20:42
Und den AST, da habe ich jetzt neulich mit einer anderen Community, mit der Pixel-Community Kontakt aufgenommen. Die haben was Ähnliches. Die haben auch einen AST, mit dem sie sich beschäftigen. Und jetzt haben wir überlegt, ob wir nicht die verschiedenen Modelle vereinheitlichen sollen. Genau. Und das war es auch schon. Noch einen kurzen Dank an mein Bacardi-Team.
21:01
Das sind die Leute, mit denen ich zusammenarbeite an der Röbenfahrt Software. Und jetzt haben wir noch 3-4 Minuten für ein paar Fragen. Ja, herzlichen Dank. Gibt es Fragen?
21:21
Und die zweite Frage ist, Lizenzverfügbarkeit, GitHub-Propositor oder wie kommt man an? Es ist prinzipiell sogar Vortrans 2012 zu weit entteilen. Also man kann Drive-Data-Types und so ein bisschen theoretisch auch objektnotiert und nicht alles implementiert.
21:41
Ansonsten ist es auf GitHub erhältlich F2X. Ja, ich kann da nachher nochmal die Adresse aufschreiben. Apache-2-Lizenz. Also frei verwendbar.
22:05
Ich habe das nicht ganz so richtig verstanden. Geht es darum sozusagen, Vortran-Code mit Python-Code zusammen zu verbinden, dass man eben beides zusammenlaufen lassen kann oder geht es darum, eben den kompletten Vortran-Code in Python zu übersetzen? Also das schien mir sozusagen jetzt die Schussrichtung zu sein am Ende,
22:20
aber ganz sicher war ich nicht... Nee, es geht schon darum, Vortran-Code aus Python aufzurufen. Das heißt, der Vortran-Code bleibt wie er ist und ich generiere ein Interface. Ah, okay, okay. Weil sonst hätte man ja irgendwie die Struktur wie immer gut oder schlecht ist irgendwie aus Vortran übernommen, wenn man den Python gegossen hat. Das ist... Das Pixel macht genau das Umgekehrte neben Python-Code und versucht daraus Vortran-Code zu generieren,
22:41
um Python-Code zu beschleunigen. Ah, okay. Aber so ein Vortran nach Python-Compiler habe ich bisher noch nicht von gehört. Das würde tatsächlich glaube ich nicht... Ja, das wäre auch die Frage, wie ist das mit der Geschwindigkeit dann? Aber das ist noch nicht probiert worden. Die Richtung ist die andere sinnvollere tatsächlich. Alles klar, danke.
23:03
Also meine Frage zielt tatsächlich auch auf die Geschwindigkeit. Also dieses Tool übersetzt den bestehenden Vortran-Code. Wie stellt es denn sicher, dass dieser Vortran-Code auch schnell ist? Nee, das Tool übersetzt ihn nicht. Also du hast ein Vortran-Modul. Das wird einfach in eine Shared-Library kompiliert. Ist fertig übersetzt. Genau. Und dann... Also ich...
23:20
Aus dem Cale-Code generiere ich dann quasi das Interface um von Python die Vortran-Routine aufrufen zu können. Alles klar. Cool.