WEBVTT 00:00.000 --> 00:12.760 Thank you for joining. Let's start. So the next talk is by Daria Klimashetska on physics 00:12.760 --> 00:14.760 in Julia, Floresjers. 00:14.760 --> 00:29.080 All right, so today I will talk a bit about implementing physics in Julia using to quite 00:29.080 --> 00:36.920 important packages, Unitful JL and differential equations JL. If you had heard about Julia 00:36.920 --> 00:43.560 yet, it's the next big thing in scientific modeling. I believe those words describe it quite 00:43.560 --> 00:51.160 well. Julia comes for the syntax, stay for the speed, because it has the Python-like syntax 00:51.160 --> 01:02.760 and the speed of C. But I will not talk about it here, because my concept I will be presenting 01:02.760 --> 01:11.440 is applicable to all kinds of programming languages, not only Julia. Let's start with some 01:11.440 --> 01:19.440 words by Richard Feynman, a famous physicist and a noble prize winner, who once said for those 01:19.440 --> 01:24.880 who want some proof that physicists are human, the proof is in the idiocy of all the different 01:24.880 --> 01:33.720 units which they use for measuring energy. That's why packages like Unitful JL are insanely 01:33.800 --> 01:42.760 useful. They allow to attach units to numerical values in the code, which makes the code 01:42.760 --> 01:50.040 much more readable. Let's take for example the constant G. When we see the units, it's clear 01:50.040 --> 01:57.880 that it's gravitational acceleration and not just some random letter G in the code. It also makes 01:57.880 --> 02:07.560 the code much more maintainable. Unitful also provides tools for conversion, so you don't have to 02:07.560 --> 02:13.800 think about what a femtosecond is or how to convert some ancient units from the article. 02:16.920 --> 02:25.640 It also during the compile time, it checks if the values are dimensionally compatible, 02:26.520 --> 02:37.560 so that we don't add meters to seconds, for example. It also lets you check if the variable 02:37.560 --> 02:46.760 you're using is length or time. It's quite useful and prevents the dimensionality errors in your code. 02:47.000 --> 02:57.640 Besides, when you're plotting your data, it also prevents units automatically to the labels, 02:58.680 --> 03:05.560 but I will come back to that in a bit. What's very important, using Unitful JL, 03:05.560 --> 03:15.560 ensures absolutely no runtime overhead. The other package I was talking about is differential equations 03:15.880 --> 03:25.640 to describe what it does. Let's start from a simple pendulum problem, such as the one shown in 03:25.640 --> 03:32.600 the picture. Some of you may remember from school that it is described by the differential 03:32.600 --> 03:40.040 equation shown on the slide. That equation can be translated into the code in a form of a function, 03:40.040 --> 03:49.240 shown here, which calculates the differential of the state vector. 03:52.360 --> 04:01.240 The differential equations JL lets you solve the problem described by this function in just 04:01.240 --> 04:08.200 two lines of code. The first one defines an ordinary differential equation problem 04:08.920 --> 04:16.680 using the function, the initial state vector, and the time span. And the second one, you just need to 04:18.520 --> 04:24.360 type ODE dot solve, and that's all you need to do. The differential equations JL, it's 04:25.640 --> 04:32.120 very advanced package. It solves not only ordinary differential equations, but also partial differential 04:32.200 --> 04:38.920 equations, it runs on CPU, on GPU, has built in mechanics like adaptive time stepping. 04:40.760 --> 04:47.560 So it's one of the main reasons people use Julia. And yeah, when you solve the equation, 04:47.560 --> 04:54.360 you can just print the output, and we can see that the pendulum changes its position periodically 04:54.360 --> 05:01.640 just as we would expect. And also, we can see that the unit will append that the units 05:01.640 --> 05:10.600 automatically to the labels. So when we have these two very useful packages, why don't we try 05:10.600 --> 05:18.840 combining them together? Let's declare all our constants with the units, and try solving it 05:18.840 --> 05:27.480 using differential equations JL. Unfortunately, that will not work. The differential equations 05:27.480 --> 05:36.760 solver will return error that our values are not compatible with the values demanded by the 05:36.760 --> 05:45.880 solver. What does the community say about that? Well, the errors appear quite often. 05:46.840 --> 05:55.000 The suggested solutions are just dropping the units or using only the very basic solvers, 05:55.000 --> 06:02.200 not the most compatible with our problem. So yeah, that kind of is the point. 06:04.040 --> 06:11.160 I believe that the solution can be found in a book by Percy Bridgman, also an Nobel Prize winner. 06:11.240 --> 06:17.240 Where it's written the astute observer, Fourier was the first astute observer, 06:17.240 --> 06:24.040 notices that the equation remain true when the size of the fundamental units is changed. 06:25.160 --> 06:32.280 Therefore, we can say that physics consists of two parts. One part is mathematical model, 06:32.280 --> 06:39.160 and the other part are constants. Mathematical model by definition does not hold any units. 06:39.960 --> 06:47.400 The units are only in the constants. Therefore, if we look at it from the program, it's point of view. 06:47.960 --> 06:53.240 We can say that the constants in the units are just injectable dependency. 06:54.760 --> 07:04.680 So, if we build a code thinking about that, we can declare all our constants with the units, 07:05.640 --> 07:11.800 everyone, every constant from all of the code, in one instance, such as the main staple here. 07:14.280 --> 07:20.600 Then we can define the function describing the problem, but we have to remember to pass the constants 07:21.400 --> 07:30.440 as part of the parameters in the function. Then those three lines of code appear that can be summarized 07:31.400 --> 07:39.400 to just create a named table that holds the constants, but is stripped of the units. 07:40.920 --> 07:49.080 And then if we try to solve it, it will work. So, basically what I just told you is that if we strip 07:49.080 --> 07:58.920 the units it will work, but that's not the point. The point is that this approach will also work with 07:58.920 --> 08:09.320 the units. If we inject our function with our dependency holding the constants and the units, 08:11.480 --> 08:24.520 here is calculated one step of the solver, and later I check if the calculated state vector 08:24.600 --> 08:33.160 is the same dimension as the initial state vector. And as we can see from the on the screenshot 08:33.160 --> 08:42.760 from the terminal, these two are the exact same one, same dimension. So, our function works with the 08:42.760 --> 08:51.480 units too. So, the take home message from the stock is that there is actually no unit full 08:51.480 --> 08:59.400 real and differential equations, real problem. Our stem equation should just be declared that it's 08:59.400 --> 09:07.000 invariant to the units we use, because the units are only an injectable dependency. 09:09.400 --> 09:17.400 And as it was shown by my colleagues, this approach can also be applied to other 09:17.400 --> 09:25.640 grid compiled text, such as Python combined with non-py and pined, where it also solved the over the 09:25.640 --> 09:33.080 issue. Yeah, so let's apply unit our testing and unique diagnostic numerics. 09:34.120 --> 09:40.760 And yeah, this is not a work around. It's just applying the physics principle in your code. 09:40.760 --> 09:52.120 So, it is also part of the example I propose to add to differential equations, 09:52.120 --> 10:01.080 JL documentation. So, if you have any comments or any questions, you can either ask me here, 10:01.080 --> 10:06.520 because we have some time as I see, or you can leave a comment under the full request. 10:07.480 --> 10:10.120 So, yeah, thank you for our attention. 10:18.840 --> 10:20.840 Thank you questions. 10:20.840 --> 10:36.440 Hi, thanks for the talk. I don't know if you're familiar with type theory, but don't you think 10:37.560 --> 10:45.400 in physics we could solve equations or calculate something with, I don't know, 10:45.400 --> 10:55.960 constants or functions defined as, as, with a type, because from what I understand in your talk, 10:55.960 --> 11:07.320 it's, um, how can I say? For what I understand is like a work around, because you don't have 11:07.400 --> 11:14.040 types for variables or something. I don't know if I'm clear. 11:14.040 --> 11:26.600 I mean, there won't be the units while solving the numeric out part of our code, but the units 11:26.600 --> 11:35.880 can just easily be attached again after, to the solution. So, it just lets you keep your code 11:35.960 --> 11:41.960 kind of organized to the numerical part and to the physical part of the code. 11:41.960 --> 11:49.160 But my question is, if you use language with the type system, don't you think it would be 11:49.160 --> 12:00.040 more easy to work with units, so it's saying like your variable g is a ms something of type ms, 12:00.120 --> 12:06.520 I don't know. Do you think it's, uh, I don't think I understand it to be honest. 12:11.080 --> 12:23.880 Oh, yes, this is the question. Well, I, I use, uh, well Julia provides a way to do with the units, 12:23.880 --> 12:31.880 so that you don't have to worry about that. Uh, like, you know, the conversions and stuff, 12:31.880 --> 12:41.320 it's very useful in the code. And I don't think that using other language would, or, well, 12:41.400 --> 12:46.600 actually have that much. And yeah, okay, thank you. 12:53.080 --> 12:57.480 Uh, there are questions. Let's think this speaker again.