 to read this. Mathematical diseases in climate models and how to cure them. And I don't have the slightest idea what these two guys are talking about now. And when I asked them, they said, ah, just tell them people. It's about next generation climate models and how to build them, which is cool. Throw that on Twitter. And please welcome Ali Ramadan and Valadin Khurvi. Can you guys hear us? Is this OK? I'll stand back a little bit. OK, cool. Thank you. So if you guys saw the last talk by Carla Liberan, or Carla Labyrinth or something, so we're kind of expanding on her talk a little bit. So she talked a lot about kind of uncertainties, uncertainties in climate models. And one point that she did make was that most of the uncertainty actually comes from humans, but there's a really huge uncertainty that also comes from the models. So we're talking more about the model uncertainties, which is kind of uncertainties because of unknown or missing physics, kind of how to cure them. So this will be kind of a weird talk. So I'll talk a little bit more about the climate modeling part and then kind of how to cure them involves using new programming languages. And that's where Valentin will talk about Julia. So we'll kind of just start with maybe just giving kind of an idea of why it's so hard to model the climate. So maybe you've seen images like this a lot, where it's like a satellite image basically of clouds. It's used for like weather forecasting. But you can immediately see there's lots of really small clouds. So basically if you want to build the climate model, you got to be able to resolve all the physics in these clouds. So you can actually zoom in a lot. So the clouds look pretty big over here, but if you zoom in on kind of Central America, then you see even smaller clouds. And if you zoom in even more, so say you zoom in on the Yucatan Peninsula, then you can see the clouds are really, really small. So they're like maybe five smaller or some of the clouds are 100 meters or something. And as the last talk kind of suggested, most climate models, they resolve things up to 50 kilometers. So anything smaller than 50 kilometers, the climate model can't really see. So you have to kind of take that. And it kind of has that count for that, because clouds are important. If you have more clouds, then that reflects some of the heat out. So maybe you cool, but it also traps more of the heat in, so maybe you warm. And if you have more clouds, maybe you warm more, but if you have less clouds, maybe you warm even more. So it's kind of unsure. We actually don't know if clouds will make the climate warmer or if they'll make the climate cooler. So it's important for your climate model to kind of resolve or see these little clouds. So kind of where the mathematical disease comes in is that we don't know what equation to solve. We don't know exactly what physics to solve to see to kind of resolve the effect of these little clouds. So it's kind of the mathematical disease. We don't know how to do it. So you instead, you use what's called a parametrization, which is the mathematical disease. So in the atmosphere, the big mathematical disease is clouds. But if you look at the ocean, you kind of get a similar, you have also similar mathematical diseases. So if you, for example, this is model output. We don't have good satellite imagery of the oceans. So if you look at, for example, model output from an ocean model, high resolution ocean model, here it's kind of centered on the Pacific. So you can kind of see Japan and China and the white kind of lines. Those are stream lines or the lines tell you where the water is going. So you could see a lot of kind of straight lines. You see this current off of Japan, but you see lots of circles. So the circles are these eddies and they're kind of the turbulence of the ocean. They move, they kind of stir and mix and transport a lot of salt or heat or carbon or nutrients or marine life or anything. It's the main way the ocean kind of moves heat from the equator to the pole, kind of stirs things around. So they're really important for kind of how carbon moves in the ocean, for how the ocean heats up. And here they look pretty big, but again, you can zoom in and you'll see lots of small scale structures. So we're gonna switch to a different model output and different colors. So here it's kind of the same area. So you see Japan in the top left, although it's being plotted as vorticity, so you don't have to know what that is. It's kind of a measure of how much the fluid or the water is spinning. But the point is that you have lots of structures. So there's lots of big circles, but there are also lots of really little circles. And again, your climate model can only see something up to like 50 kilometers or 100 kilometers. But as you can see here, there's lots of stuff that's much smaller than 100 kilometers. So if you superimpose kind of this grid, maybe that's your climate model grid. And basically for the climate model, every one of these boxes is like one number. So you can't really see anything smaller than that. But there's important dynamics in physics that happens at like 10 kilometers, which is a lot smaller than what the climate model can see. And there's even important physics that happens at like 100 meters or 200 meters. So if you wanna know what the climate will look like, you need to know about the physics that happens at 200 meters. So to give an example of some of the physics that happens at 10 kilometers, here's kind of a little animation where this kind of explains why you get all these eddies or all the circles in the ocean. So a lot of times you have say hot water, say in the north, so the hot water here is all in orange or yellow, and you have a lot of cold water. So the cold water is in the south and it's purple. And then once you add rotation, you end up with these eddies because what the hot water wants to do, the hot water is lighter, it's less dense. So it actually wants to go on top of the cold water. So you usually have cold at the bottom, hot at the top. So you have heavy at the bottom or light at the top. So when you add, without rotation, the hot water will kind of just go on top of the cold water, but when you have rotation, you end up, it kind of wants to tip over, but it's also rotating. So you kind of get this beautiful swirling patterns. These are kind of the same circular eddies that you see in the real ocean. But this model here is like 250 kilometers by 500 kilometers and it's like one kilometer deep. So you need a lot of resolution to be able to resolve this stuff, but not, your climate model doesn't have that much resolution. So some of the features here, like the sharp fronts between the cold and the hot water, your climate model might not see that. So maybe if you don't resolve this properly, you get the mixing rates wrong, or maybe the ocean is the wrong temperature or something. So it's kind of important to resolve this stuff. Another one, the color scheme here is really bad. I'm sorry, but another one, for example, is here everything's on a 100 meter. So it's a cube of 100 meters on each side, and you're starting with 20 degrees Celsius water at the top, you have 19 degrees Celsius water at the bottom initially. So it's kind of your, as you go deeper in the ocean, the water gets colder. And then if you can imagine in the ocean, kind of at night, it's kind of cold. So the top is being cooled, and you end up with cold water at the top, and the cold water wants to be at the bottom. So it ends up sinking, and you get all this convection going on. So this is happening in a lot of places in the ocean, you get a lot of mixing at the top. You get this kind of layer at the top of the ocean that's kind of constant color, constant temperature. So this mixed layer is important for the ocean. So knowing how deep that mixed layer is, and knowing how much of the water is being mixed is also important for climate. But you can imagine, this happens on very small scales. So your climate model has to know something about what's happening at this scale. So this isn't, I guess the mathematical diseases in the ocean is the climate model cannot see this. So it has to do something else that's maybe unphysical to resolve this stuff. And that's the mathematical disease, I guess. And aside from the ocean and the atmosphere, you also have the same problem with sea ice. So this is kind of just a satellite picture of where sea ice is forming off the coast of Antarctica. So you get winds that kind of come off the continent, they're kind of blowing all the ice that's being formed, the way you see all these little lines and streaks and they kind of merge into sea ice. But this whole picture is like 20 kilometers. So the climate model doesn't see this, but somehow it has to represent all the physics. And you have kind of similar things happening with soil moisture, land, dynamic vegetation, aerosols. So these are kind of three places with pretty pictures, but say if you look at the atmosphere, so it's not just clouds, you also have aerosols, which are like little particles or sulfates that are important for kind of cloud formation and maybe atmosphere chemistry. But again, we don't fully understand the physics of these aerosols. So again, you have to kind of parameterize them. And same thing with kind of convection. So maybe your climate model doesn't resolve a very deep convection in the atmosphere. So it also has to parameterize that. So I guess you have many kind of mathematical diseases in the atmosphere, so I'm not expecting you to understand everything in this picture, but the idea is the atmosphere is complicated. There's no way a climate model is gonna kind of, you know, figure all this out by itself. And again, you could do something similar for the ocean. So we kind of just showed animation for like two little parts of these, but the point is, you know, the ocean is not kind of just a bucket of water standing there, so there's lots of stuff happening deep inside the ocean. And some of it we think is important for climate, some of it we don't know, some might not be important. But again, a lot of this happens on like very small spatial scales, so we don't know or the climate model can't always resolve all this stuff. And again, the same thing with kind of sea ice, lots of small scale stuff is important for sea ice. And I think one person asked about kind of tipping points and there's kind of two with like sea ice that are pretty important. One of them is this sea ice albedo feedback. So if you have sea ice that melts, now you have more ocean and the ocean can absorb more heat, but now the earth is warmer, so it melts more sea ice. So as soon as you kind of start melting sea ice, maybe you melt even more sea ice and eventually you reach an earth with no sea ice. So there's kind of research into that stuff going on, but that's a possible tipping point. Another one is this kind of marine ice heat stability instability at the bottom of the ice shelf. So if you start melting water or if you start melting ice from the bottom of the ice shelf, then you create kind of a larger area for more ice to melt. So maybe once you start melting an increasing sea level, you just keep melting more and more and increasing sea level even more. But again, it's kind of hard to quantify these things on like 50 or 100 year timescales because it all happens on like very small scales. So yeah, the point is there's lots of these kind of parametrizations or mathematical diseases and once you start adding them all up, you end up with lots and lots of kind of parameters. So this is a really boring table, but the point is so this is like one parametrization for like vertical mixing in the ocean. It's basically the process that I showed the rainbow color movie about to say a climate model for that, trying to kind of parametrize that physics might have like 20 parameters. And you know some of them are crazy like a surface layer fraction of like 0.1 or something. And usually they keep the same constants for all these values. Usually it's like someone in like 1994 came up with these 20 numbers and now we all use the same 20 numbers. But maybe they're different in like the Pacific or the Atlantic or like maybe they're different when it's summer and winter. And the problem is there's many of these parametrizations. So here's like 20 parameters, but then you have a lot more for clouds. You have a lot more for sea ice and you add them all up. Suddenly you have like 100, maybe up to 1,000 kind of tunable parameters. Kind of going back to this plot that was showed at the last talk, you can see kind of all the models kind of agree really well from like 1850 to 2000 because they're all kind of being, they all have different kind of parameters but they all get kind of tuned or like optimized. So they get the 20th century correct. So they get the black line correct. But then when you run them forward so you run them to like 2,300, they all are slightly different. So they all start producing different physics and suddenly you get a huge like red band. So that's saying you have lots of model uncertainty. So that's kind of, I don't know, some people might say like, oh this like tuning process is like optimization. It's like not very scientific. They'd be kind of right. It's kind of like in the past it's kind of like the best we've had. But I think we should be able to do a little bit better, better than that. So just to give you an idea, some people would say, why don't you just, you know most of the physics why don't you just resolve all the physics, you know? But say if you want to do like a direct numerical simulation. So that's basically saying you want to resolve all the motions in the ocean and the atmosphere. You basically need to resolve things done to like one millimeter. So if you have like a grid spacing of one millimeter and you consider the volume of the ocean and the atmosphere you basically say you need like 10 to the 28 grid points. You know that's like, imagine putting cubes of like one millimeter everywhere in the ocean and atmosphere. That's how many grid points you would need. So unfortunately you could do that, but there's not enough computer power or storage space in the world to do that. So you're kind of stuck doing something a bit coarser. Usually most climate models use like 10 to the eight grid points. So that's, you know, 10 to the 22 little. And of course you don't want to just run a big climate model once. You know, you need to run them for very long times. Usually like you run them for a thousand years or 10,000 years. You want to run many of them because you want to collect statistics. So generally you don't run at the highest resolution possible. You run kind of at a lower resolution so you can run many, many models. So because you can only use so much resolution, it seems that parametrizations or these kinds of mathematical diseases you have to live with them, you got to use them. But at least one idea is, you know, instead of using numbers that somebody came up with in 1994, you might as well try to figure, you know, better numbers or maybe, you know, if the numbers are kind of different in different places, you should find that out. So one thing you could do or one thing we are trying to do is get the parametrizations to kind of agree with like basic physics or agree with observations. So we have lots of observations and we can run kind of high resolution simulations to resolve a lot of the physics and then make sure when you put the parametrization in the climate model, it actually gives you the right numbers according to basic physics or observations. But sometimes that might mean, you know, different numbers in the Atlantic and the Pacific or different numbers for the winter and the summer. And you have to run many high resolution simulations to get enough data to do this. But in these days, I think we have enough computer power to do that. So to kind of do all these high resolution simulations, we ended up building a new kind of ocean model that we run on GPUs because GPUs are all faster for giving us these results so that we ended up, usually most climate modeling is done in Fortran. We decided to go with Julia for a number of reasons which I'll talk about. But the left figure is kind of that mixed layer or boundary layer turbulence kind of movie, but instead of the rainbow color map, now it's using the more reasonable color maps that looks like the ocean. The right is that old movie. So we're just generating tons and tons of data from using simulations like this and then hopefully we can get enough data and figure out a way to explain the parametrizations. But it's kind of a work in progress. So a different idea that might be more popular here, I don't know, is instead of kind of using the existing parametrizations, you could say, okay, well, now you have tons and tons of data, maybe you just throw in like a neural network into the differential equations. Basically you put in the physics you know and then the neural network is responsible for the physics you don't know. So for example, most people here might not, I also don't want to talk about differential equations because that would take a long time. So just imagine that the equation in the middle is kind of what the climate model needs to solve and the question marks are kind of physics we don't know. So we don't know what to put there. But maybe you could put in a neural network. So number one is kind of like a possible parametrization or a possible way you could try to parametrize the missing physics where the neural network is kind of responsible for everything. We find that doesn't work as well. So instead maybe you tell some of the physics. So maybe you tell it about Q, which is like the heating or cooling at the surface. And then it's kind of responsible for resolving the other stuff. But it's still a work in progress because the blue is kind of supposed to be your data, the orange is supposed to be the normal, they don't agree. So it's still a work in progress, but hopefully we'll be able to do a bit better. So this is kind of stuff that's like a week or two old. But to kind of reach a conclusion, that's these for my half of the talk. So the reason I personally like Julia as a climate modeler is we were able to kind of build an ocean model from scratch, basically in less than a year. And one of the nice things is that the user interface are kind of the scripting and the model backend is all in one language. Whereas in the past, usually you write the high level in like Python and maybe the backend is in like Fortran or C. And we find, you know, when we use Julia, it's just as fast as our legacy model, which was written in Fortran. And one of the nicest things was that basically you're able to write code once and using there's a native GPU compiler. So basically you write your code once, single code base and you go to CPUs and GPUs. So you don't have to write two different code bases. And yeah, we find generally because it's a high level language where we're kind of more productive, we can give a more powerful user API. And Julia kind of has a nice multiple dispatch backend so that we find that makes it easy for users to kind of extend the model or hack the model. And there's some people would say the Julia community is pretty small, but we find there's a pretty big kind of Julia community interest in scientific computing. So we found kind of all the packages we need are pretty much available. So with that I'll kind of conclude my half by saying there's most of the uncertainty in climate modeling basically comes from humans because we don't know what humans will do. But there's a huge model uncertainty basically because of physics we don't understand or physics the climate model cannot see. You can't resolve every cloud and every wave in the ocean. So you got to figure out a way to account for them. So that's what our prioritization does. And we're trying to kind of use a lot of computing power to kind of make sure we train or come up with good prioritizations instead of kind of tuning the model at the end. And we're hoping this will lead to better climate predictions maybe it will, maybe it won't. But at least, you know, even if it doesn't hopefully we can say we got rid of the model tuning problem. And hopefully we can make, we find it that software development for climate modeling is easier than if we did it in Fortran. Oh, so I will say this kind of an advertisement but I'm looking to bike around Germany for a week and apparently you can't take the next bike out of Leipzig. So if anyone is looking to sell their bicycle or wants to make some cash, you know, I'm looking to rent a bicycle. So yeah, if you have one come talk to me please. Thank you, Duncan. So one big question for me always is how can we as technologists help, right? I think most of us in this room are fairly decent with computers. The internet is not necessarily new online for us. But how do we use that knowledge to actually impact real change? And if you haven't, there's a fantastic article very dream.com slash climate change which lists like all the possible or not all the possible, a lot of good ideas to think about and go like, okay, do my skills apply in that area? Well, I'm a computer scientist. I do programming language research. So how do my skills really apply to climate change? How can I help? And one of the things that took me in this article was how and one of the realization and why I do my work is that the tools that we have built for scientists and engineers, they're rather poor. Computer scientists like myself have focused a lot on making programming easier, more accessible. What we don't necessarily have kept the scientific community as a target audience. And then you get into this position where models are written in a language, 1470, 14 is a rather nice language, but it's still not one that is easily picked up and where you will find enthusiasm in younger students for using it. So I work on Julia and my goal is basically to make a scientific computing easier, more accessible and make it easier to access the huge computing powers we have available to do climate modeling. Ideas, if you are interested in this space, is you don't need to work on Julia necessarily, but you can think about maybe I'm to look at modeling for physical systems, modeling, like one of the questions is can we model air conditioning units more precisely get them more efficient or any other technical system? How do we get better efficiency but we need better tools to do that? So the language down here as an example is Modellica, there's a project right now, Mordia that is trying to see how we can push the boundary there. The language up here is Fortran, you might have seen a little bit of that in the talk beforehand, and it's most often used to do climate science. So why programming languages? Why do I think that my time is best spent to actually work on programming languages and do that in order to help people? Well, Wittgenstein once said the limits of my language are the limits of my world. What I can express is what I think about, and I think people who are multilingual know that, that sometimes it's easier to think about certain things in one language than it is in the other one. But language is about communication, it's about communication with scientists, but it's also about communication with the computer. And too often programming language fall into that trap where it's about oh, I wanna express my one particular problem, or I wanna express my problem very well for the compiler, for the computer, I wanna talk to the machine. But I found that programming languages are a very good tool to talk to other scientists, to talk in a community, and to actually collaborate. And so the project that Ali and I are both part of has I think 30-ish, I don't know, the numbers are big. The big group of climate scientists model us and we have a couple of numerical scientists, computer scientists and engineers, and we are all working the same language, being able to collaborate and actually work on the same code instead of me working on some low-level implementation and Ali telling me what to write. And that wouldn't be really efficient. So yes, my goal is to make research easier. Do we really need yet another high-level language? That is a question I often get, it's like why Julia and not, why are you not spending your time and effort doing this for Python? Well, so this is a small example, this is Julia code. It looks rather readable, I find. It doesn't use a semantic white space. You may like that or not. It has all the typical features that you would expect from a high-level dynamic language. It is using the MIT license, it has a built-in package manager, it's very good for interactive development, but it has a couple of unusual ones. And those matter, you need, if you wanna simulate a climate model, you need to get top performance on a supercomputer, otherwise you won't get an answer in the time that it matters. Julia uses just in time ahead of time compilation. The other great feature is that Julia's written in Julia, so I can just look at implementations. I can dive and dive and dive deeper into somebody's code and don't have a comprehension barrier. If you ever have spent some time and tried to figure out how Python sums numbers under the hood to make it reasonably fast, good luck. It's hard, it's written in C and there is a lot of barriers in order to understand what's actually going on. Then reflection and meta-programming, you can do a lot of fun stuff, which we're gonna talk about. And then the very big one for me is that you have native GPU code generation support, so you can actually take Julia code and run it on the GPU, you're not relying on libraries, because libraries can express the things that was where written in them. So early on last December, I think we met up for the Climate Science Project and after deciding on using Julia for the entire project, they were like, we're happy with the performance, but we have a problem. We have to duplicate our code for GPUs and CPUs. I'm like, what really? It can't be, I mean, I designed the damn thing, it should be working. Well, what they had at that point was basically always a copy of two functions, where one side of it was writing the CPU code and the other side was implementing the GPU code. And really, there were only a couple of GPU-specific parts in there, and if anybody has ever written GPU code, it's this pesky, which index MI calculation. Whereas the for loop on the CPU, it just looks quite natural. And I was like, well, see, come on. What we can do is we can just write a kernel, so we take the body of the for loop, extract it into a new function, add a little bit of sugar and magic to call GPU kernels and CPU functions, and then we're done. Problem solved. Well, the code roughly would look like this, and actually this, you can copy and paste this, and it should work. And so you have two functions, one of them launches, you extract your kernel, then you write a function, it takes another function and runs that function in a for loop, or it launches that function on the GPU. And then you have this little GPU snippet, the only bit of this actually on the GPU, which calculates the index and then calls the function F with the index argument. I'm like, I'm done here. My contribution to this project is done. Well, they came back to me and were like, no, this is not good enough. And I was like, why? Well, the issue is they needed kernel fusion, so that's the process of taking two functions and merging them together. I'm like, okay, fine. Why do they need that? Because if you wanna be wide average efficient GPU code, you need to be really concerned about the numbers of global memory loads and stores. If you have too many of them, or if they are irregular, you lose a lot of performance. And we need good performance, otherwise we can't simulate to the resolution all events. They also actually wanted to use GPU functionality in low-level control, so they wanted to look at their kernels and use shared memory constructs. They wanted to do precise working, minimizing the number of registers used. And they really cared about low-level performance. And they were like, well, we can't do this with the abstraction you gave us because it builds up too many barriers. And I could have given, I feel more typical computer science answer, which would have been, okay, give me two years and I will come back to you. There's the perfect solution, which is like a cloud cloud in the sky. And I'll write you a spoke language that does exactly what you need to do. And at the end, we have a domain-specific language for climate simulation that will do finite volume and discontinuous clerking and everything you want. And I will have a PhD, great, fantastic. Well, we don't have the time. The whole climate science project that we are on has a rather accelerated timeline because the philanthropists that are funding that research are, well, if you can't give us better answer anytime soon, it won't matter anymore. So I sat down and was like, okay, I need a botch. I need something that has minimal effort, quick delivery. I need to be able to fix it if I get it wrong the first time around, and I did. It needs to be hackable. My collaborators need to understand it and actually be able to change it. And it needs to be happening yesterday. Well, Julia is good at these kind of hacks. And as I've learned, you can actually let them go into bespoke solutions and have better abstractions after the fact so that you can actually do the fancy computer science tricks that I really wanted to do. The project is called GPUify Loops because I couldn't come up with a worse name. Nobody else could, so we stuck with it. It's a macro-based, so Julia, you can write syntax macros that transform the written statements into some other statements. So you can insert code or remove code if you want to. It right now targets CPUs and GPUs and we are talking about how do we get multi-threaded into the story, how do we target more on different GPUs. There are other projects that are very similar. So there's Ocar, which is where a lot of these ideas are coming from on the OpenACC in C++ does something very similar. But basically, you write a for loop, you write an at loop in front of it, which is a magic macro that takes a transformation and you have two index statements. And now you just say, I want to launch it on a GPU and it magically does a job. Okay, fantastic. So let's peek under the hood. The entire implementation of the macro at loop without the error checking that didn't fit on the screen is a couple of lines. So everything is here. And basically, I'm just manipulating the for loop so that on the GPU, it only iterates one iteration per index and on the CPU, it iterates all of the indices because a CPU is single threaded and a GPU is many, many multi-threaded course. There's a little bit of magic hidden in the isDevice function because how do I know where I'm running and if you're curious how to do that and we can talk afterwards. But otherwise, it's a very simple, straightforward transformation. It's written in Julia. It's a Julia function and yeah. So you don't need to understand the code here. I just wanted to show how quick it can be to write something like this. If you know anything about GPU programming at all, there should be a little voice in the back of your hand that is like, wait a second. How can you run a dynamic programming links on a GPU? That shouldn't be possible. Well, Julia can run on the GPU because it has a lot of meta programming facilities for the port for stage programming so I can generate code based on a specific call signature. It has introspection reflection mechanisms that allow me to do some interesting stuff in the background. It is built upon LVM, which is a common compiler infrastructure and so I can actually write a staged function that will generate an LVM specific code for my one function and do that during compile time. And it's a dynamic language that tries very hard to avoid runtime uncertainties and this is one of the challenges if you're getting into Julia is to understand that when you're writing code that has a lot of runtime uncertainties, you get relatively slow performance or as fast as Python but if you work with a compiler and you avoid runtime uncertainties, you can get very fast code and you can run your code on the GPU. Basically that's the litmus test. If you can run your code on the GPU, you did your job well and it provides tools to understand the behavior of your code. So avoiding runtime uncertainty. It does that and I don't have the time to go too deep into that so there's actually a paper about this. It has a type system that allows you to do some sophisticated reasoning, type influence to figure out what your code is doing. Multiple dispatch is actually helping us quite a lot in making it easier to de-virtualize calls. It uses aggressive specialization and just in time compilation. And so just looking a little bit closer at some of these topics, if you want to look at the entire pipeline that flow when you start writing a function and call it what happens through the Julia compiler, you have tools to introspect and all of these are on the right-hand side here and then you have tools to interact on the left-hand side where you can inject code back into the compiler. The other thing is Julia has dynamic semantics. So when you def, you can at runtime redefine a function and it would call the new function and it uses multiple dispatch. So if I'm looking at the absolute value call here, which of the 13 possible methods will it call? In C++ or in other programming languages it's called a virtual function call. So is in Julia everything a virtual function call? No, this is one of the important points is when we call a function, let's say we call sine of x, we look at the type of the input arguments and then we first of all look at which function is applicable to our input argument. So in this case it would be the real down here because flow 64 is a subtype of real. So we choose the right method using dispatch and then we specialize that method for the signature. So the rule in multiple dispatch to remember is we're calling the most specific method, whatever specific might mean. So if you have this example where we have function f, which has three different methods and we have an integer argument that can be matched on x or on y and then we have a floating point argument on y and we call this with a one comma hello, well we will select the method that is most specific for this argument which would be the number one here. On the other hand if when we have a float 64 in the second position then we recall the second method. Now what happens if I pass in an integer in the first position and a floating point in the second position? Well you will get a run time error because we can't make this decision what is the most specific method. So that's just something to keep in mind. Method specialization works very similarly when you call a method for the first time this method sign right now has no specializations and then I look, I call it once and Julia will insert a specialization just for float 64 before that it could have been a float 32 or float 64 for this method. So Julia specializes and compiles methods on concrete call signatures instead of keeping everything dynamic or everything ambiguous. You can introspect this process and there are several markers that are code lowered or code typed that will help you understand that process. I think I don't have enough time to go into detail here but just as a note if you ever look at this the percentage four means it's an assignment so if you reference it later, so in line five we will iterate on the four value and then we can look at the type information that Julia infers out of that call. So we're calling the function Mandel with a UN32 and you can see how that information propagates through the function itself. And then if we actually do aggressive, we do aggressive inlining and optimizations and de-virtualization and so in the end we don't have calls anymore, we only have the intrinsics that Julia provides on which programs are actually implemented so this is a unsigned less than integer function. So we are using type inference as an optimization to find static or near static sub-programs. It allows us to do aggressive de-virtualization, inlining constant propagation but it raises problems of cation validation. So in bygone days this used to be the case. I could define a new function G after calling G1 a new function F after calling G1 and I would get the old result back. That's bad, that's counter-intuitive, that's not dynamic. So in Julia 1.0 and I think 05 and 06 already we fix that so we're invalidating the functions that have dependencies on the function we just changed. That can increase the latency of your program. If you change a lot of the functions and you recall them, well, we need to do a lot of work every time. We do constant propagation, so as a very simple example we try to reduce, we try to explore as much information as possible and so if you call, if you write a function F and you call the function sign with a constant value we actually will just return you the constant avoiding the calculation of the sign entirely and that can be very important during hot calls in a cycle. This can sometimes go wrong or Julia has heuristics in order to decide whether or not these optimizations are valuable and so when you introspect your code you might see results that are not quite what you want. So we don't know what the return value is, it's just a tuple. We know it's a tuple, nothing else. So the heuristic decide not to specialize. But the nice thing about Julia and where we get performance for it is that we can actually do four specialization and hopefully at some point we will make the compiler smart enough that these edge cases disappear. So I can use some secrets and force the specialization to happen and then I can actually infer the precise return type of my function. Another thing to know when you're coming from a traditionally object-oriented programming language is that types are not extensible, extendable, so you can't inherit from something like IN64. You can only subtype abstract types. We do that because otherwise we couldn't do a lot of optimizations. When we look at programs you can't never assume that you won't add code. We had dynamic programming language at any time in the runtime of your program you can add code. And so we don't have closed world semantics which doesn't allow us to say, hey, by the way, we know all possible subtypes here. You might add a new type later on. By saying that concrete types are not extendable, we get a lot of the performance back. So personally for me, why do I like Julia or why do I work on Julia? It works like Python, it talks like this and runs like Fortran, that's my five-second sales pitch. It's very hackable and extendable. I can poke at the internals and I can bend them if I need to. It's built upon LVM so in reality for me as a compiler writer it's my favorite LVM frontend. I can get the LVM code that I need to actually run. But for users that's hopefully not a concern if you do a job right. And it has users in scientific computing and I in a prior life was doing a lot of scientific computing in cognitive science, writing models and I care about these users because I've seen how hard it can be to actually make progress when the tools you have are bad. And my personal goal is to enable scientists and engineers to collaborate efficiently and actually make change. Julia is a big project and Climber is a big project. There are many people to thank and with that I would like to extend you an invitation if you're interested. There's Julia Korn every year where we have a developer meetup. Last year we had about 360 people, so much smaller than CCC. But next year it will be in Lisbon. So come join us if you're interested and if you wanna meet scientists who have interesting problems and are looking for solutions. Thank you. Time for questions and answers. Are there any questions? Yeah, we've got microphones over there. So just jump to a microphone and ask your questions so that everybody could hear them. What do you mean when you say that Julia talks like Lisb? And how is this a good thing? Well, it talks like Lisb, but it doesn't look like Lisb. I assume that's what you mean. It doesn't have that many places. But now, Lisb has rather powerful metaprogramming capabilities and macros. And so we have a lot of that. If you read a little bit about the history of Lisb, the original intention was to write MLisp, which would be Lisb with a nice syntax. And I think Julia is my personal is MLisp. It has all the nice features, but it doesn't have the bracket syntax. Okay, thank you. Thanks for the talk. My question is regarding the first part of the talk. If I understand correctly, you're simulating a deterministic system there. So there's no additional noise term or anything, right? Well, if you had infinite precision, I think it would be deterministic. But I think by kind of design, turbulence itself is not deterministic. Well, it's a chaotic system. But the discretized version itself is deterministic. You don't have a Monte Carlo part where you have some noise that you would add to which might actually be justified from the physics side, right? Well, I think if you ran the same simulation again, you would not get. Well, I think if you ran on the exact same machine, you would get the same answer. So in that sense, it is deterministic, but if you ran on a slightly different machine, like truncation error on the 16th decimal place could give you a completely different answer. Sure. So the point, am I allowed to continue? Yes, of course. There's no one else. Well, there is one person else, so you can continue a few minutes if you want to. Thanks. So the point I was trying to make is if you add noise in the sense that it's a physical system, you have noise in there, it might actually allow you to not solve a PDE or discretize a PDE, but get a stochastic simulation itself, which might be interesting because it often can make things easier. And also, you mentioned neural differential equations, right? And in particular with physical systems, if you have discontinuities, for example, the DT integral can actually be quite the problem. And there is work on, to just plug my colleague's work, control neural differential equations where you can actually also build in these discontinuities, which might also be interesting for you guys. Also, maybe we should talk because I don't know much about that stuff, where we're kind of just starting off. I think the other stuff we've been doing is maybe hopefully continuous, but maybe we'll hit discontinuaries. I don't know, we should talk, though. Thank you. And also the math is beautiful and has no sickness. It's the physics that might need to change. I'm a mathematician, I had to say that. Okay, yeah. The physics is ugly, trust me. Just to jump in quickly, we do have stickers. And I... And they have cookies, too. They are in the cookie box. And on, I think, day four, somebody from our community is giving a Julia workshop. And we're trying to set up an assembly space and hopefully that goes out as well at some point. Go ahead, please. Hello. Also one question for the first part of the talk. I wanted to ask if it's possible or if you are using dynamic resolution in your climate models, where you maybe have smaller grid size near the vortices and larger in the areas that are not that interesting. Oh, like adaptive grids? Yes. So I think we mostly do that in the vertical. So usually in the ocean, the things are interesting close to the surface, so you have more resolution there. But as you go deeper, things get less interesting. So you put less resolution there. Generally, I think in general of the art, people have asked that before, why do you always use constant grids? Why don't you use these adaptive grids on your global models? And usually the answer I've heard, I don't know if it's very convincing. I think generally there hasn't been that much research or people who do research into adaptive grids for climate models, their funding gets cut. But the answer I've heard is that a lot of the climate, a lot of the atmosphere and ocean is turbulent. So if you, especially if you do kind of adaptive refinement, then it just kind of adapts everywhere because there's kind of turbulence everywhere. But yeah, I don't, I'm not, I guess for our simulations, we're kind of just, some of the numerical methods are only fast if you run it on like kind of a regular grid. So that's the reason we don't use adaptive grids for our simulations, but in general adaptive grids for climate models is interesting, but I haven't heard like, it seems like there needs to be more research in that area. So I don't know if I answered your question, I kind of just ran through it. You did, thanks. So go ahead, please. Yeah, just a few questions about this. I think I have repped quite a bit of legacy Fortran code and Python. And my question is, would that be a simple pass converting Fortran code to Julia preferably automatically? Do you have any ideas about this one? You can do it. You drew your code, we look like Fortran code. So you haven't won anything. So yes, as a good starting point, you can do that, absolutely. But you can also just call Fortran from Julia and then gradually move over. I generally don't want people to reword their code, except if there's a good reason, like starting from scratch sometimes helps. That can be a good reason or if you say the solutions, we don't have the necessary experts to work with the old solution anymore. But in generally, if you have Fortran code, I would just say, well, call Julia from Fortran or Fortran from Julia. Get that up to speed and then start transitioning piece by piece, where it makes sense. So any more questions? No more questions. That's an early wrap, Dan. Ali Ramadan and Valentin Truavi. Thank you very much.