 Mathematische Diszellen in Klimatmodellen und wie sie sich umgehen. Und ich habe keine schreckliche Idee, was diese beiden Leute jetzt über reden. Und wenn ich sie fragte, dann sagten sie, ah, einfach die Leute, es ist um die Klimatmodelle zu sprechen. Als ich sie gefragt habe, haben sie einfach gesagt, ich soll über die nächsten Modelle von Klimamodellen sprechen und wie man damit umgeht. Bitte begrüßt die Sprecher. Können Sie uns hören? Ist das okay? Ich werde wieder ein bisschen zurück. Okay, danke. Wenn ihr den letzten Vortrag gesehen habt, dann werden wir das etwas ausführen. Sie hat viel über Unsicherheit in Klimamodellen geredet. Und eine Sache, die sie erwähnt hat, ist, dass die meiste Unsicherheit von Menschen kommt, aber auch ein großer Teil der von den Modellen kommt. Und wir sprechen mehr über die Modellunsicherheit, die Unsicherheit wegen unbekannter oder nicht bekannter Physik und wie wir sie behandeln. Wir sind aufgeteilt in zwei Teile. Ich werde über das Klimamodell reden und dann werden wir über Julia reden und wie man die neue Programmiersprache verwendet für die Modelle. Wir fangen an, euch eine kurze Idee davon zu geben, warum Klima so schwer zu modellieren ist. Ihr habt solche Bilder vielleicht schon mal gesehen, das sind Satelliten im Bilder von Wolken für Wettervorhörsaage verwendet. Und ihr könnt schon sehen, das sind sehr viele kleine Wolken. Und wenn man ein gutes Klimamodell machen will, muss man alle kleinen Wolken auflösen. Man kann da viel reinsummen auf zentralen Amerika. Dann sieht man noch kleinere Wolken und wenn man noch weiter reinsumt, wenn man auf die Ukatan-Halbinsel einsumt, dann sind die Wolken sehr, sehr klein. Einige Wolken sind nur 100 Meter groß und wie der herrige Vortrag gesagt hat, nutzen die meisten Klimamodelle Auflösung bis zu 50 Kilometer und alles was klein ist, als die 50 Kilometer kann das Modell nicht sehen. Und wir müssen das irgendwie einbeziehen, weil Wolken sind wichtig und wenn wir mehr Wolken haben, beeinflusst das, wie viel Wärme abgegeben wird oder eingefangen wird. Wenn man mehr Wolken hat, ist es vielleicht wärmer, wird mehr aufgewärmt. Wir wissen das nicht so wirklich, ob Wolken das Klima wärmer oder kälter macht. Also es ist wichtig für das Klimamodell, diese kleinen Wolken aufzulösen. Und wo die mathematischen Krankheiten hinkommen, ist, dass wir nicht wissen, welche Gleichungen wir aufschreiben sollen, welche Physik wir lösen müssen, um den Effekt dieser kleinen Wolken zu sehen und dass dieser Effekt dieser mathematischen Krankheiten, dass wir nicht wissen, was wir machen, die große mathematische Krankheit im Klima-Wurder-Essen-Krankheiten. Wenn wir uns den Ozean anschauen, hat man da auch eine ganz ähnliche mathematische Krankheit. Also dieses Modell, also hier, es wäre jetzt kein gutes Satellitenbild von den Ozeanen, aber wenn man hier ein Ozeanen-Modell anguckt, hoch aufgelöstes Modell, dann auf dem Pacific, da sieht man hier oben Japan und China und die weißen Linien, das sind Strömungslinien, da sieht man, wo das Wasser lang geht. Man sieht also sehr viele Strömungslinien, zum Beispiel hier an der japanischen Insel und man sieht auch Kreise, das sind Eddyströme, das sind Turbulenzen im Ozean, die durchmischen sich und transportieren Salz und Hitze oder Marinusleben, alle diese Dinge, das sind die Dinge, die der Ozean benutzt, um Hitze zu transportieren und zu durchmischen. Und das ist wichtig, wie die Teile im Ozean sich bewegen, wie es sich aufheizt. Und hier sehen sie relativ groß aus. Man kann wieder reinzoomen und man sieht, das sind also sehr kleinskalige Strukturen. Wir gucken uns mal ein anderes Modell an, andere Farben auch, hier ist eine ähnliche Region, man sieht links oben wieder Japan, aber es wird jetzt dargestellt, es ist anders dargestellt, ihr müsst nicht wissen, was es ist, es ist ein Maß, wie sehr sich das Wasser sich dreht. Man sieht sehr viele Strukturen, große Kreise, aber sehr viele kleine Kreise. Und man sieht jetzt hier 50 oder 100 Kilometer in den meisten Modellen, aber wie man sehen kann, gibt es sehr viele Dinge, die sehr viel kleiner sind. Als diese 100 Kilometer, also wenn man hier zum Beispiel so ein Gitter drüber legt, so ein Klimamodellgitter, dann sieht man für das Klimamodell ist jede Box eine Zahl, man sieht nichts, was kleiner ist. Aber es gibt sehr viele wichtige Dynamik in der Physik, die in der Größenordnung von 10 Kilometer sind, was sehr viel kleiner ist, als das, was die Klimamodelle sehen können. Und es gibt sogar auch physikalische Phänomene, die bei 100 Metern oder 200 Metern Größenordnung passieren. Und wenn wir wissen wollen, wie das Klima dann aussieht, dann müssen wir die Physik verstehen, die bei 200 Metern passiert. Also wenn wir mal ein Beispiel anschauen für die Physik, die da passiert, auf 10 Kilometern, hier ist eine kleine Animation, wo erklärt wird, wo diese Kreise im Ozean entstehen. Also man hat zum Beispiel im Norden heißes Wasser. Das ist jetzt in dem Fall alles als orange oder gelb dargestellt. Das kalte ist im Süden hier die Lila eine Farbe. Und wenn man jetzt Rotationen mit einführt, dann sieht man diese Eddyströme. Das heiße Wasser ist leichter, es ist weniger dicht. Das heißt, das läuft hier über das kalte drüber. Und das ist schwerer, das das kalte Wasser. Und ohne Rotation bewegt sich einfach das heiße Wasser auf die Oberfläche. Aber jetzt rotiert es eben, und man sieht diese sich verwirrenden, diese kreisförmigen Eddyströme, die man auch im tatsächlichen Ozean sieht. Und das sind jetzt 250 mal 500 Kilometer. Das heißt, man braucht eine sehr große Auflösung, um dieses Zeug auflösen zu können. Und die üblichen Klimamodelle haben die Auflösung nicht. Und einige dieser scharfen Kanten zwischen kalten und heißen Wasser, das sieht man möglicherweise gar nicht im Klimamodell. Und wenn man das ordentlich auflöst, dann kriegt man zum Beispiel die falschen Durchmischungsraten oder das falsche Temperatur im Ozean. Deswegen ist es wichtig, diese Werte aufzulösen. Ein anderes Beispiel hier ist wieder ganz grässliches Farbschema. Aber hier sieht man ein Beispiel. Alles ist 100 Meter. Das heißt, also ein 100 mal 100 Meter großer Kubus. Und man startet mit 20 Grad Celsius, warmem Wasser. Und umso tiefer man runter geht, umso kalter wird. Und man kann sich vorstellen, in der Nacht wird es kalt, die Oberfläche wird abgekühlt und das kalte Wasser möchte nach unten. Das heißt, es sinkt hier nach unten und das gibt Konvektion. Und das passiert an vielen Orten im Ozean. Da wird er so an der Oberfläche durchmischt. Und man bekommt diesen zusätzlichen, diese Kurs sich in der Ebene an der Oberfläche. Und das ist wichtig für den Ozean und das ist wichtig auch zu verstehen, wie dick dieser Durchmischungs-Ebene ist. Und man kann sich also jetzt auch vorstellen, dass das auf sehr kleinen Skalen passiert, das Klimamodell muss also eine gewisse Information darüber haben, was auf dieser Skala passiert. Und das ist, dass die mathematische Krankheit im Ozean, denn das Klimamodell kann das nicht sehen. Es muss irgendwas tun. Es wäre unphysikalisch, das sonst aufzulösen. Abgesehen von dem Turbulenz im Wasser hat man das Problem mit Eis. Hier formt sich Eis vor Antarktika. Man kriegt jedes Wind, das Eis, das sich gerade bildet, weg weht. Und dann sieht man diese Linien da. Und das ganze Bild sind 20 Kilometer und das Klimamodell sieht das nicht. Aber man muss trotzdem irgendwie die ganze Physik abbilden. Und man hat ähnliche Dinge passieren mit dynamischer Vegetation und Aerosolen. Und es sind Plätze mit schönen Bildern. Aber wenn man die Atmosphäre guckt, das sind nicht nur Wolken, sondern man hat auch Aerosole, so kleine Teilchen wie Sulphate, die wichtig für Wolkenbildung sind und wichtig für Chemie. Aber wir verstehen die Physik nicht wirklich, also wissen wir nicht wirklich, wie sie parametrisieren sollen. Man hat Konvektionen und dieses Klimamodell kann vielleicht nicht alle Konventionen in der Atmosphäre auflösen. Und das sind viele mathematische Krankheiten in der Atmosphäre. Ich erwarte nicht von euch, dass ihr alles in diesem Bild versteht. Die Atmosphäre ist kompliziert. Es gibt keine Möglichkeit, dass ein Klimamodell alles selbst rausfindet. Man kann sowas ähnliches für den Ozean machen. Man kann ja durch alle Punkte gehen, aber die wichtige Sache ist, dass der Ozean nicht nur einmal mit Wasser ist, sondern viele Dinge gehen vor. Und manche könnten wichtig sein für Klima, manche nicht. Wir wissen nicht wirklich was und alles passiert auf sehr kleinen, räumlichen Skalen. Und das Klimamodell kann das nicht alles auflösen. Und dasselbe für Eisen, mehr viele Sachen. Viele Sachen sind wichtig für Eisen, mehr. Und es gibt zwei Punkte, wo das Klima kippt. Das eines Seee-Eis-Albedo-Effekt. Wenn man anfängt, Seee-Eis zu schmelzen, dann sinkt der Albedo, dann wird mehr Eis geschmolzen und irgendwann endet man ab mit einer Erde ohne Eis. Und das ist eine wichtige Sache. Und das andere ist die Instabilität auf dem Boden des Meers. Wenn man anfängt, Eis am Boden des Chefs zu schmelzen, dann hat man eine größere Fläche, wo Eis schmelzen kann. Und dann vergrößert man einfach nur die Fläche, wo das Eis schmelzen kann. Und dann schmelzt mehr Eis und dann schmilzt das Eis immer schneller. Und das ist aber schwer, dass alles auf 50 oder 100 Jahre zu prognostizieren, weil es auf sehr kleinen Skalzen passiert. Also der Punkt ist, dass es sehr viele Parameter oder mathematische Krankheiten gibt. Und wenn man anfängt, die alle aufzuordieren, endet man mit sehr, sehr vielen Parametern. Endet man bei sehr, sehr vielen Parametern. Das hier ist eine Tabelle für vertikales Mischen im Ozean, das farbige Bild, die farbige Animation, was ich vorhin gesagt habe. Die Parameter, die mal für die physikalische Animation braucht, sowas wie 20 Parameter. Also die Reibung an der Oberfläche, so was nicht, 0,1, total verrückt. Und es ist auch etwas willkürlich. Dieses eine Modell hat 20 Parameter, wir benutzen den festen, aber vielleicht sind sie unterschiedlich im Atlantik und Pacific im Sommer und im Winter. Es könnte alles unterschiedlich sein. Wir haben hier 20 Parameter, wir haben viel mehr für Wolken, wir haben viel mehr für Eis. Und am Ende enden wir ab mit 100 bis 1000 Parametern, die man alle verenden kann. Und wir können diesen Plot angucken, der im letzten Vortrag gezeigt wurde. Und die ganzen Modelle funktionieren gut, von 1850 bis 2000. Die haben alle unterschiedliche Parameter, aber die werden alle gut eingestellt. Und dann bis zum 20. Paramet, bis zum Jahr 2000. Die schwarze Linie funktioniert ganz gut. Aber wenn man sie in die Zukunft prognostiziert, werden die immer unsicherer und die gehen auseinander. Und da sieht man dieses riesige, rote Band mit sehr viel Unsicherheit. Und einige Leute würden sagen, dass diese Optimisierung, diese Parameter finden, nicht wirklich wissenschaftlich ist. Wir haben einen Punkt. Das ist nicht wirklich großartig, aber das Beste, was wir hatten. Aber wir sollten in der Lage sein, etwas besser zu sein, um euch eine Idee zu geben, warum wir nicht einfach alle Physik auflösen. Sagen wir, wir wollen eine direkte nummerische Simulation der ganzen Erde machen von der Atmosphäre und der Meeres. Dann muss man bis zu einem Millimeter herunter alles auflösen. Und dann das Ozeanvolumen und die Atmosphäre sich anguckt, braucht man 10 bis 28 Gitterpunkte. Das kommt raus, wenn man den Gitter über die ganze Erde legt. Man könnte das machen, aber unglücklicherweise gibt es nicht genug Computerpower in der ganzen Welt, um das zu machen. Meistens Klimamodelle benutzen 10 bis zu 8 Gitterpunkte. Man will das auch nicht nur einmal laufen lassen, sondern mehrmals für 1000 bis 10.000 Jahre. Man will viele davon laufen lassen, weil man Statistik haben will. Man lässt man nicht die höchste Auflösung, die möglich ist, laufen, sondern man will viele Wiederholungen haben und nimmt eine niedrigere Auflösung. Deswegen muss man diese Parameterisierung einfach benutzen. Wir können die Nummer verwenden, mit denen jemand 1949 sich ausgedacht hat. Man kann die Parameter verändern und gucken, was passiert. Eine Sache, die wir machen, ist die Parameterisierung. Wir versuchen die Parameterisierung, zumindest teilweise, mit Physik in Übereinstimmung zu bringen und sicherzustellen, dass wenn man die Parameterisierung in das Modell reinsteckt, dass man die grundlegende Physik und die grundlegenden Obstwablen wieder gewinnt. Das heißt, dass man unterschiedliche Parameter für Sommer und Winter und verschiedene Ozeane machen. Man muss Hoch-Auflösung-Simulation machen, aber im Moment haben wir die richtige Computerpower dafür. Wir benutzen Modelle auf der GPU, weil es uns schnellere Sultate gibt. Wir verwenden nicht Fortranoffil, wir verwenden Julia. Auf der rechten Seite sehen wir ein altes Video mit einem alten Programm auf der rechten Seite. Das ist aktuell noch eine andere Idee, die wir gerade haben. Das könnte ein bisschen populärer sein. Statt die bestehenden Parameterisierungen zu verwenden, wissen wir, wir haben ganz viele Daten. Deswegen versuchen wir jetzt, ein neuronales Netz hineinzuwerfen mit den Differenzialgleichungen und damit die Physik zu beschreiben, die wir noch nicht kennen. Ein Beispiel ist, ich möchte jetzt nicht über Differenzialgleichungen reden, denn es würde eine ganz lange Zeit dauern. In dieser Gleichung sehen wir Fragezeichen. Diese Fragezeichen sind Physik, die wir noch nicht kennen. Wir versuchen dafür, neuronale Netze zu verwenden. Unser primäres Ziel ist, neuronale Netze zu verwenden, um diese fehlende Physik zu beschreiben. Ich möchte euch nicht über die ganze Physik erzählen. Zum Beispiel haben wir hier Kuh, das ist die Wärme. Das alles ist noch ein bisschen Arbeit im Fortschritt. Es ist immer noch Sachen, an denen wir gerade arbeiten und der Zukunft wird es hoffentlich besser. Ich möchte nicht zu lange darüber reden, um eine Phase zu ziehen für meinen Teil des Talks. Warum ich Julia so sehr mag, wir konnten ein Modell von Grund aus aufbauen. Unser Nutzerinterface und unser Backend ist alles in einer Sprache. Früher war das eine Mischung aus Python und Fortran, Fortran und C. Wir haben herausgefunden, wenn wir Julia verwenden, ist es ungefähr genauso schnell wie unser alter Fortran-Code. Das Schöne ist, dass man bei Julia Code 9.1. mal schreiben kann. Man hat eine einzige Codebasis, dann kann man mit einer Codebasis sowohl CPU und GPU verwenden. Man hat also nicht zwei verschiedene Codebasis. Wir mögen Julia, weil es eine sehr hohe Sprache ist. Es hat Multiple Dispatch. Mit Multiple Dispatch kann man ganz einfach Software erweitern oder auch daran drum hacken. Die Julia Community ist aktuell noch relativ klein, aber sie ist um meine Hälfte mal abzuschließen. Die Probleme mit den Klimamodellen ist, dass Klimamodelle von Menschen kommen. Klimamodelle ist, viele Dinge sind noch unsicher. Es gibt viele Probleme wegen fehlender Physik. Man kann nicht einfach alles auflösen, weil jede Wolke und jeden Ozean muss man idealerweise beschreiben. Mit entsprechend Computerpower kann man größere Paradiesierungen finden, um Physik zu beschreiben. Unter Umständen führt das zu besseren Klimamodellen. Vielleicht, vielleicht auch nicht. Wir hoffen, dass Klimamodelle in Julia einfacher sind. Das ist ein bisschen Advertising für mich. Ich suche gerade nach einem Fahrrad oder es zu kaufen oder zu mieten. Wenn jemand einen Satz, soll er bitte zu mir kommen. Vielen Dank. Eine große Frage für mich ist immer, wie können wir als Technologen Wissenschaft helfen? Meiste Wissenschaftler sind ganz gut. Mit Computern interniert sich Neuland für uns. Aber wie nutzen wir das, um wirklich einen Fortschritt zu bringen? Es gibt einen fantastischen Artikel bei worrieddream.com. Der sehr viele Ideen auflistet, wo man seine Skills anwenden kann. Ich bin ein Computer, wie kann ich meine skills, meine Fähigkeiten gegen Klimawandel anwenden? Eine der Sachen, die ich, als ich den Artikel gelesen habe, festgestellt habe und warum ich diese Arbeit mache, ist, dass die Werkzeuge, die wir haben für Wissenschaftler und Ingenieure, sind sehr schlecht. Wir als Technologen, die Informatiker haben viel daran gearbeitet, die Werkzeuge einfacher zu machen, aber wir haben nicht wirklich daran gedacht, Wissenschaftler als Usergruppe zu haben. Und dann haben wir Fortschritts eine sehr schöne Sprache, aber es ist nichts, was man einfach so lernt und wo man schnell Enthusiasmus bei Studenten aufbauen kann. Julia mag ich, weil ich es nutzen will, um die Computerpower einfacher zugänglich für Wissenschaftler und Ingenieure zu machen. Wenn ihr daran interessiert seid, dann müsst ihr nicht unbedingt an Julia arbeiten, aber ihr könnt darüber nachdenken über Modellierung von physikalischem System zu arbeiten. Eine der Fragen ist, können wir jedes technische System effizienter machen mit diesen IT-Tools, Beispieler und Modellika. Die Frage zur Zeit ist, wie wir da die Grenzen weiter machen können, dass da oben ist Fortran. Habt ihr vielleicht die Grenzen meiner Sprache gesehen? Das ist oft benutzt in Wissenschaften. Warum programmiere Sprachen? Warum glaube ich, dass programmiere Sprachen meine Zeit am besten genutzt ist, um programmiere Sprachen zu verbessern und damit Leute zu helfen? Wittgenstein hat einmal gesagt, die Grenzen meiner Sprache sind die Grenzen meiner Welt. Was ich ausdrücken kann, ist worüber ich denke. Die Multilingual sind wissen, dass es einfacher ist, in einer Sprache zu denken als in anderen. Aber bei Wissenschaft geht es um Kommunikation. Zum einen mit anderen Wissenschaftlern und zum anderen mit dem Computer. Wissenschaftler sagen oft, sie wollen ihr eigenes Problem für die Maschine ausdrücken oder für andere Wissenschaftler ausdrücken. Das Programmiersprachen ist ein guter Weg mit anderen Wissenschaftlern in der Gemeinschaft zu reden und zu kommunizieren. Was wir beide gemacht haben, ist, dass eine Gruppe von etwa 30, auf jeden Fall eine große Gruppe, daran arbeiten. Wir haben numerische Wissenschaftler, wir haben Ingenieure, wir haben Wissenschaftler. Wir alle arbeiten am selben Code und wir arbeiten nicht an einer niedrigleveligen Implementation. Das wäre nicht wirklich effizient. Also meine Idee ist, Wissenschaft einfacher zu machen. Brauchen wir noch eine andere Hochlevelsprache? Das ist eine Sprache, die mir aufgestellt wird, warum Julia und nicht Peißen. Das ist ein kleines Beispiel. Das ist eine Julia Code. Das ist ein sehr lesbares Beispiel. Du magst das oder nicht? Du hast all die typischen Sprachen, die man erwarten würde von dieser Sprache, MIT-Lizenz, Bildung, eingebauter Package Manager und interaktive Entwicklung. Aber es hat auch ein paar unübliche Features und diesen Tipps. Wenn man ein Klimamodell simulieren will, braucht man eine sehr, sehr gute Performance auf dem Supercomputer. Sonst kriegt man keine Antwort in der Zeit, die wichtig ist. Julia ist da sehr gut im Moment. Ich kann tiefer und tiefer und tiefer in jemandes Code gehen und habe da keine Verständnisprobleme. Wenn ihr jemals probiert habt, rauszufinden, die Peißen, Nummern sumiert, um es halbwegs schnell zu machen, das ist sehr, sehr schwer rauszufinden. Viel Glück sind es, sehr viele Hürden auf dem Weg zu verstehen, was tatsächlich passiert im Hintergrund. Man kann da sehr viele lustige Sachen machen. Worüber wir reden werden, und was wichtig ist, dass man GPO-Kode Generation hat. Das heißt, man kann Julia Code nehmen und auf der GPU laufen lassen. Man ist nicht auf Bibliotheken angewiesen. Letzten Dezember haben wir uns getroffen für das Klimawandelprojekt. Als wir uns auf Julia geeinigt haben, waren wir glücklich mit der Performance, aber wir hatten ein Problem. Wir mussten unseren Code für GPUs und GPUs duplikieren. Ich konnte das nicht glauben. Ich habe das Design, das sollte funktionieren. Was Sie damals hatten, ist eine Kopie von zwei Funktionen. Die linke Seite, den GPU-Kode, und rechts Seite, den GPU-Kode. Es gab nur ein paar GPU-spezifische Teile. Und falls irgendjemand GPU-Kode geschrieben hat, ist diese zweite Linie hier. Die Vorschleife im CPU schaut ganz natürlich. Ich habe gesagt, wir können einfach einen harten Kern schreiben. Dann eine Funktion, also ein Kern schreiben laus, eine Funktion separieren für den GPU-Kode, und dann sind wir schon fertig. Das hier ist etwa die Lösung. Ihr könnt das kopieren, einfügen, und das sollte funktionieren. Eine extra hier, den Kernel. Dann hat man eine Funktion, die entweder auf dem CPU oder auf dem GPU läuft. Und diese andere Teil hier ist das einzige, was auf dem GPU anders ist, der den Index berechnet und dann ausgibt. Und ich bin fertig hier. Das ist meine Arbeit. Und Sie sind zurückgekommen zu mir und haben gesagt, das ist nicht gut genug. Und der Grund, warum Sie brauchen Kernelfusion, macht Ihnen zu einer. Wenn man ungefähr halbwegs effizienten GPU-Kode schreiben will, muss man sehr sicher sein, dass man die Loads und Stores von Speicheroffizient ausnutzt. Sie wollten außerdem auch GPU-Funktionalität und Low-Level-Funktionalität verwenden. Sie wollten an Ihre Kernel schauen und Shared-Memory verwenden. Sie wollten die Anzahl der Register, die verwendet werden, minimieren. Und wir haben gesagt, wir können das nicht machen mit der Abstraktion, die ihr euch gegeben habt, denn da sind viel zu viele Barrieren da drin. Ich hätte Ihnen eine viel mehr Computer Science Antwort geben können. Gebt mir ein paar Jahren und kommt zu mir zurück. Dann gibt es die perfekte Lösung mit einem schönen Wolkenprogramm. Das wird euch alles machen, was ihr wollt. Das wird Final Volume haben, das Continuous Galerkin und eine schöne humanisch-spezifische Sprache dafür. Aber Sie sagten zu mir, na da, ich habe dafür nicht die Zeit. Und der Grund dafür ist, weil die Philanthropen, die die Forschung finanzieren, die haben uns gesagt, wenn ihr uns eine Antwort nicht sofort gebt, dann ist die einfach nicht mehr wichtig. Also, ich habe irgendwie einen kleinen Push gebraucht, eine kleine, mit einem minimalen Arbeit und es soll schnell irgendwie funktionieren. Es muss erweiterbar sein, es muss hackbar sein und es soll irgendwie funktionieren. Und es soll natürlich gestern fertig sein. Julia ist sehr gut an diesen Artigen Hacks, weil Julia ganz langsam in diese Lösungen hineinwachsen lassen kann. Dann hat man die Lösung nach einer gewissen Zeit für Computer Science Tricks spielen, die wir gerne hätten. Deswegen bin ich mit dem Programm GBO File Loops übrig geblieben. Es ist makrobasiert. Das heißt, das sind kleine Schnippets, die geschriebenen Statements und andere Statements transformieren. Aktuell kann es Target, aktuell kann es GPUs in CPUs verwenden und wir sprechen gerade, wie wir schnelle GPUs auch unterstützen können. Es gibt zum Beispiel OKer und OpenAPCC in C++, von der viele von diesen Ideen kommen, die gründlichen Idee ist, man schreibt eine Follower und ein Add Loop davor und in diesem Add Loop gibt es zwei Index Statements und da unten sagt man Add Launch an der CPU und auf magische Weise macht das das dann. OK, super. Lass uns mal unter die Haube schauen hier. Das ist eine grobe Implementierung von Add Loop ohne Failure Checking. Aber die grobe Implementierung alles ist da. Im Großen und Ganzen manipuliere ich die For Loop, damit es an der GPU einfach nur eine Iteration pro Index macht. Während an der CPU iteriert es alle Indizes. Der Gedanke ist, dass die CPU single threaded ist, aber die GPU viele Threads unterstützt. Es gibt ein kleines bisschen Magie, die hier versteckt ist in der ist device Funktion, weil die Frage ist, wie führt man das Ganze aus, das ist ein bisschen Magie. Aber davon abgesehen ist es eine einfache Transformation, es ist komplett geschrieben in Julia. Ihr müsst hier den Code nicht verstehen, ich wollte euch nur zeigen, wie schnell man sowas schreiben kann. Wenn ihr irgendwas wisst über GPU Programmierung, da sollte es jetzt einen kleinen Notch geben in eurem Kopf. Wie kann man eine dynamische Programmiersprache auf der GPU ausführen? Julia kann auf der GPU ausführen, weil es sehr viele Metaprogrammierungsmöglichkeiten hat. Das heißt, es kann Code generieren, basierend auf verschiedenen Support Funktionen. Es hat Introspection und Respection, die erlauben verschiedene Dinge im Hintergrund machen. Es ist auf LLVM aufgebaut. LLVM ist eine Compiler-Infrastruktur. Das heißt, ich kann eine Stage-Funktion schreiben, die LLVM-spezifischen Code generiert und den Zurkunft-Teilzeit einfügt. Julia ist eine dynamische Sprache, die sehr versucht, Unsicherheiten zur Laufzeit zu vermeiden. Das heißt, wenn man Code hat, der sehr viele Unsicherheiten zur Laufzeit hat, bekommt man eine eher langsame Laufzeit, während wenn man mit einem Compiler arbeitet, der Laufzeit-Unsicherheiten mit einbezieht, dann kann es den Code schneller kompilieren. Julia kann das. Julia gibt einem Werkzeuge, um sich genau einzuschauen, was unter der Haube passiert. Ich habe leider nicht die Zeit, da genau reinzuschauen. Es gibt ein Paper darüber. Da könnt ihr was mehr finden. Es hat ein Type-System, das möglichst genau reinzuschauen, wie das Ganze funktioniert. Ich möchte jetzt ein paar von diesen Sachen etwas genauer anschauen, wenn man an die genaue Pipeline sich anschaut von, wenn man eine Funktion schreibt und sie aufhört, was da genau passiert in dem Compiler. Das gibt euch eine Liste von Tools, die man hat, das Ganze genau anzuschauen, da reinzuschauen und Tools, mit denen man mit dieser Pipeline interagieren kann, wo man Dinge einfügen kann. Das andere ist, Julia hat dynamische Semantik. Das heißt, zur Laufzeit kann man wirklich eine Funktion definieren und ausführen. Das benutzt Multiple Dispatch. Das bedeutet, dass, wenn ich hier zum Beispiel mir den Absolute Value Call anschaue, die Frage ist, welche von diesen 13 verschiedenen Funktionen wird das genau aufrufen? In C++ in anderen Sprachen nennt man das ein Virtual Function Call. Die Frage, die sich stellt, ist, bei jedem Funktionsaufruf ein virtueller Funktion, das ist nicht so. Der Punkt hier ist, wenn man das Julia, den Typ des Inputarguments, anschaut und dann schaut, dass sich an welche Funktionen zu diesem Typ genau anwendbar sind. Das heißt, in diesem Beispiel ist es die Real Funktionen hier unten, weil Flow 64 ein Untertyp von Real ist. Das heißt, die richtige Methode wird hier ausgewählt mit Dispatch und dann wird sie spezialisiert für genau diese Typ. Das heißt, das Wichtigste bei Multiple Dispatch, was man im Blick halten sollte, ist, man ruft die spezifischsten Methode auf. Das heißt, in diesem Beispiel haben wir eine Funktion F, die drei verschiedene Methoden hat. Wir haben ein Integer Argument, das in X oder Y gemetzt werden kann und in Y ist es ein Float Argument. Das heißt, jetzt mit 1, Hello aufrufen, dann wird die spezifischste Methode aufgerufen, was in diesem Fall diese hier ist, und deswegen Nummer 1. Auf der anderen Seite, wenn wir ein Float im zweiten Argument haben, rufen wir die zweite Methode auf. Die Frage ist jetzt, was passiert, wenn ich ein Integer in der ersten Position aufrufe und ein Float im zweiten Argument nun, weil Julia nicht die Entscheidung treffen kann, welche die spezifischste Methode ist. Nun, schauen wir uns Method Specialization an. Method Specialization passiert, wenn man eine Methode zum ersten Mal aufruft. Hier hat die Methode keine Spezialisierung, wenn ich jetzt aber einmal aufrufe, dann fügt Julia eine Spezialisierung nur für Float 64 vor in diese Methode ein. Jetzt ist Float 32 und Float 64 sein, jetzt kann es nur noch Float 64 sein. Das heißt, Julia spezialisiert und kompliert Methoden und behält nicht alles dynamisch. Man kann diesen Prozess sich anschauen, zum Beispiel CodeLowert, man hat Makros, wie zum Beispiel CodeLowert und CodeTyped, den kann man sich die Details anschauen. Ich glaube, ich habe nicht genug Zeit, um hier in die Details mehr anzuschauen, denn 4 bedeutet hier ein Assignment, das heißt, wenn man es jetzt hier zum Beispiel wie in Zeile 5 aufruft, dann wird iterate auf den Wert von 4 aufruft führt. Man kann sich die Typinformation, die Julia inferiert anschauen, man kann sich hier anschauen, wie diese Typinformation durch den Funktionsbaum durchpropagiert. Wenn wir jetzt hier eine aggressive Inlining und Optimierung durchführen, dann haben wir keine Calls mehr, dann haben wir nur Julia Intrinsics, um was Julia ausführt und was es tatsächlich ausführt. Also hier das ist zum Beispiel Anstand dessen integer Funktion. Das heißt, wir benutzen TypInferenz, um hier statische oder fast statische Unterprogramme zu führen. Also früher war das der Fall. Ich konnte eine neue Funktion definieren, G nachdem ich eine neue Funktion F, nachdem ich G einmal aufgerufen habe und ich würde das alte Resultat noch mal kriegen. Das ist nicht intuitiv, das ist nicht dynamisch. Also in Julia 1.0 und in den neueren Versionen ist das repariert. Das heißt, die Funktion wird ungültig gemacht. Die Abhängigkeiten hat auf die Funktion, die wir gerade geändert haben. Das kann die Latents erhöhen. Wenn man viele Funktionen überschreibt, dann kann das dazu führen, dass man viel Arbeit machen muss jedes Mal. Wir propagieren Konstanten. Also als einfaches Beispiel, wir versuchen, wir versuchen so möglichst viel Informationen auszunutzen, die wir haben. Also wenn wir eine Funktion F schreiben und dann haben wir eine Funktion Sinus von einem konstanten Wert, dann wird da tatsächlich auch eine Konstante ausgewertet, dass die Berechnung quasi völlig vermeidet und das kann während in Aufrufen innerhalb von Schleifen sehr wichtig sein kann. Julia hat heuristische Methoden, um zu entscheiden, welche Methoden sie ausrufen sollen. Wenn man den Code sich anschaut über Introspection, dann kann das dazu führen, dass man Effekte hat, dass man z.B. nicht weiß, was hier zurückgeben werden soll. Hier sieht man z.B. ein Tupel zurückgegeben, man weiß aber nicht, was das für ein Typ haben soll. Und das Schöne an Julia ist, dass wir Spezialisierung erzwingen können. Und hoffentlich wird der Compiler irgendwann smart genug, diese Spezialfälle dann auch selbst zu entscheiden. Also wir können hier ein paar Geheimnisse benutzen, um diese Spezialisierung zu erzwingen, sodass man hier z.B. sagen kann, der Rückabewert meiner Funktion ist garantiert dieser Typ. Und auch was Wichtiges, was man wissen muss, wenn man von der traditionellen objektorientierten Sprache kommt, Typen kann man nicht erweitern, man kann also nicht ableiten von Int64, man kann nur ein Untertyp von exakten Typen bilden. Das macht man, damit man viele Optimierung, weil viele Optimierung sonst nicht möglich wäre. Wenn wir Programme anschauen, dann kann man nicht nie davon ausgehen, dass man keinen Code mehr hinzufügen kann. Das heißt, es gibt keine Semantik einer geschlossenen Welt. Es erlaubt uns nicht zu sagen, hey, wir wissen jetzt alle möglichen Untertypen. Man kann immer noch ein Untertyp hinzufügen. Wenn wir sagen, Typen sind nicht erweiternbar, dann kriegen wir viel von der Performance zurück. Für mich persönlich, warum mag ich Julia so? Warum arbeite ich an Julia? Es läuft wie Python, es spricht wie Lisp und es wird ausgeführt wie Fortran. Es ist hackable und man kann es erweitern. Ich kann die Interna verändern, wenn ich es brauche. Es baut auf LLVM auf. Das heißt, als jemand, der Compiler schreibt, das ist mein Lieblingsfrontend für LLVM, ich kann den LLVM Code, den ich brauche, tatsächlich dazu bringen, ausgeführt zu werden. Für Benutzer interessiert das hoffentlich nicht. Das hat Benutzer im wissenschaftlichen Rechnern. Ich mache im kognitiven Wissenschaften viel, schreibe da Modelle. Diese Nutzer liegen mir sehr im Herzen. Ich habe gesehen, wie schwer es sein kann, Fortschritt zu machen mit den Werkzeugen, die wir haben. Mein persönliches Ziel ist, Wissenschaftler und Ingenieure dazu zu bringen, effizient zu kollaborieren und tatsächliche Änderungen herzuführen. Julia ist ein großes Projekt. Klima ist ein großes Projekt. Es gibt viele Leute, denen wir danken wollen. Damit möchte ich euch gerne einladen. Wenn ihr interessiert seid, gibt es die Julia-Conn jedes Jahr. Da treffen sich die Entwickler. Letztes Jahr waren es 360. Das heißt, es ist sehr viel kleiner als der Chaoskongress. Letztes Jahr wird es in Lissabon sein. Wenn ihr euch dafür interessiert, kommt doch, wenn ihr Wissenschaftler treffen wollt, die interessante Probleme haben und die nach Lösungen suchen. Damit war die Übersetzung des Talks. Was meinst du, wenn du sagst, Julia spricht wie Lisp? Warum ist das eine gute Sache? Es spricht wie Lisp, aber es sieht nicht aus wie Lisp. Ich denke, das hat nicht so viele Klammern. Lisp hat sehr viele mächtige Metaprogrammierfähigkeiten und Makros, und davon haben wir ganz viel. Wenn man über die Geschichte von Lisp ließ, dann war die originale Idee, M-Lisp in der netteren Sündung zu sein. Julia ist quasi meine Weiterentwicklung von M-Lisp. Das hat die netten Features, aber nicht so viele Klammern. Danke für den Talk. Meine Frage ist bezüglich des ersten Teils des Talks. Wenn ich es richtig verstehe, dann simuliert ihr ein deterministisches System. Da ist kein Neusterm oder so was. Wenn wir beliebig genau wären, dann wäre es deterministisch. Aber Turbulenz bei Design ist ja schon nicht deterministisch. Aber die diskretisierte Version selbst ist auch deterministisch. Da ist kein Neusterm oder so was, was ihr vermutlich von der Physik allerdings klarstellen könntet. Wenn ihr dieselbe Simulation zweimal laufen lassen würdet, dann würde ihr nicht ... Wenn es auf derselben Maschine wäre, wäre es dieselbe Antwort. In dem Sinne ist es deterministisch. Aber auf einer anderen Maschine folgt der Rundungsfehler schon zu einem anderen Ergebnis. Ja, natürlich. Da ist noch einer. Da ist noch einer. Kann ich weitermachen? Ja, okay, gerne. Den Punkt, den ich rüberbringen wollte, war, wenn man Störungen hinzufügt, also im Sinne von, dass man physische Störungen hinzufügt, dann bekommt man eine stochastische Simulierung, was unter Umständen eine gute Sache wäre, weil das könnte Dinge einfacher machen und darüber hinaus. Ihr habt über neuronale differenzielle Gleichungen gesprochen und zum Beispiel über Unschnittlichkeiten und dass DT integriert könnte in der Tat ein Problem sein und er ist arbeiten darüber, wie man mit normalen differenziellen Gleichungen arbeitet, wie man diese Diskontinuität kontrollieren kann. Das könnte für euch interessant sein. Ja, vielleicht sollten wir da im Anschluss mal darüber reden, denn ich weiß nicht genau, worauf von ihr sprecht. Auch die Methode ist interessant und ist ziemlich schön und ganz viel Physik. Ja, so vertraue mir, die Physik ist ziemlich hässlich. Und nur ganz schnell, wir haben auch Sticker und Kekse gibt es auch, in der Cakesbox. Und am Tag 4 gibt es ein Julia Workshop und wir würden gerne ein Assembliespace bauen, wo wir uns treffen können. Auch eine Frage über den ersten Tag des Talks. Ich wollte fragen, ob es möglich ist, oder ob ihr dynamische Auflösung in eurem Modell findet, mit kleineren, dynamisch kleineren Gittergrößen. Wie dynamische Gittergrößen. Ja, wir machen das in den vertikalen Ebene, weil in den Ozeanen Dinge in der Nähe der Oberfläche interessanter sind, das war da unten weniger interessant. Deswegen nimmt man da weniger Auflösungen. Ich denke, ganz allgemein haben Leute natürlich das vorher auch schon gefragt, warum benutzt ihr konstante Gitter. Und die Antwort, die ich meistens gelesen habe und ich weiß nicht, ob das sonderlich überzeugend ist, es gab halt einfach nicht sehr viel Forschung dazu. Oder wenn Leute nach dynamischen Gitter, also Forschung machen auf dem Gebiet, dann wird deren Geld gestrichen. Und wenn man adaptive Verfeinerung macht, dann verfeinert das üblicherweise überall, einfach weil die Turbulenz überall ist. Aber was unsere Simulation angeht, sind einige der numerischen Methoden einfach nur schnell, wenn man sie auf einem regulären Gitter ausführt. Und ganz allgemein ist das ein interessantes Thema für Klimamodelle. Aber ich denke, da ist noch Forschung notwendig. Ich weiß auch nicht, ob ich da die Frage beantwortet habe. Das hast du. Vielen Dank. Ein paar Fragen. Ich habe bei einem ziemlich viel Legacy Fortran Code gerappt. Wäre da ein einfacher Fortran Code zu Julia zu konvertieren und idealerweise sogar automatisch habt ihr da irgendwelche Ideen? Ja, das kann man machen. Der Julia Code sieht dann aber aus wie Fortran und dann hat man nicht viel gewonnen. Also ja, als guter Startpunkt kann man das machen. Aber man kann natürlich auch einfach nur Fortran von Julia aus aufrufen. Ich möchte nicht, dass Leute ihren Code neu schreiben, das ist ein üblicherweise, außer es gibt einen sehr guten Grund dafür. Die Lösungen hat man möglicherweise die Werkzeuge gar nicht mehr um mit den alten Codes zu arbeiten. Aber wenn man ein Fortran Code hat, dann würde ich üblicher sagen, dann ruft doch einfach Julia von Fortran auf oder umgekehrt und sorgt dafür, dass das funktioniert. Und dann geht schrittweise vor, also Stück für Stück. Noch irgendwelche Fragen? Keine Fragen mehr?