 So our plan now is to go through a couple of the exercises as a demo and then we'll answer some of the interesting questions from HackMD. So should we begin? Yeah. Okay, so let's see, we've got exercise here. Yes, let's look at the exercise one first, where we are supposed to run this host name command. So what you want to do is brighten some script with an SH at the end. So that is typical for the slurm like shell scripts. One extent like ending that we also use is the slurm script. But basically in this script, you will want to write the shebang, so the interpreter, what needs to be done, and the actual program that you need to run. But in order to run it in the queue, you also need to give the resource requirements. So let's use the S batch time statement to give a time value. So Richard here is using this hour, minutes, seconds type of time format and then specifying the memory with men instead of memory, because otherwise it won't work. Oh yes, there we go. But all of these can be found on the reference page. If you, slurm will give you an error or it won't read the comment if it's reading some other form. So let's try running this. Okay, control X, save, there we go. Should I submit it? And with S batch, let's submit it. So we'll see that, okay, it run fast. So we have this job ID. And the output should be, yeah, if we look at the history. So yeah, we see that in the last 10 minutes Richard has run this serial one job. So if you look at the output, it's by default written in this slurm and the job ID file. And if we look at what's inside of it, you see that there's the host name of the, well, of the program. Yeah. Okay. Okay. We could. Well, I think the second and well, the other other steps are not necessarily something that we necessarily need to do because that's basically like they are like the output file name and the job name, you can do them with the J and J or the job name and the output flags. And you can monitor the queue interactively with this slurm watch queue. Control C will quit from that. So you will have to like, it will constantly keep it open. So if you're running some job and you want to see whether it's submitted, you should use this slurm watch queue. Yeah. Control C exits it. Let's try the second script. So in this script, we have a bit more like we use another program to do the analysis. So we don't use the host name. We use the Python program to run the actual Python code. So let's look at the SPC examples. Yeah. Python. Should I open the file or? You should probably check the path. What is the path of the Pi file? Yeah. There. It's over there. So let's open our editor and let's create a script for this Python file that calculates the Pi. Let's use an SH. Yeah. So we are using bash to launch Python. So basically, we are putting stuff there. So over here, we say to the script that you will want to launch these SPC examples, slurm Pi, Python thing. And like mentioned in the example of the exercise, we should try with greater number of tries with multiple s runs. So let's try it out. Okay. And then let's put some requirements there. So let's say we want to run it for, I don't know. Yeah, let's put first the requirements, yeah. Yeah. Like that. And let's put something like a spatch time, I don't know, 15 minutes. Okay. And then maybe a few gigabytes of memory. So just like two gigs. Okay. Yeah. And then let's see what happens. So now we can see it's running and we can watch it. So yeah, this watch will automatically update every, well, we can see from time. So now it's five seconds. I think it's something like 15 seconds or something. How often does it update? Okay. It's already finished. Control C to exit. Yeah, let's look at the output. Okay. So now we'll be called slurms. Yeah. 40481. Yes. Okay. Yes. So here we see that the script is increasingly better with increasing a number of iterations. Let's check slurms history to see what happens. So now we see the second part. The second part with the CDL 2. We see that there's many of these steps. So there's zero one and two. So these are the individual steps that that we run run. And you will see that the run times are different on the right side. You will see that the first one took 54 milliseconds. Second one 68 and the third one was already four seconds. So heavy calculating here. But basically we can monitor individual top steps. And individuals top step run times and requirements by using the S run statement. So these S run should be used like like mentioned before, they should be used when you're running some actual calculation code. You shouldn't like for every every command you run, you shouldn't run the S run, but only for those that are actually doing some calculation. And this brings us to one of the questions that was seen the HackMD that was really important, that can you run anything in this slurms script? And the answer is basically yes, you can run anything that you would run interactively. And that's the basically the idea of the serial script. So if you have a non-interactive session where you basically, let's say you load some module, you run some code, you run some other code, you go to a different folder, you run a pre-processing step, you run the post-processing step, whatever. You have many different things in your workflow. This serial job basically codifies your workflow. So these individual steps that you're taking, they are then taken by the computer in your place. So basically, if your workflow is such that let's say you need to determine yourself with your own eyes that which plot is the correct one. Like you do a plotting stage and the plotting stage is determined by you like looking at the graph itself and okay, do this analysis or something. That's not something that computer can replicate because you are like in a major part in that workflow. But if your workflow is written in a way where the computer can calculate, let's say, a value that it can use to determine which plot to choose. It can do these certain steps of setting up the environment and running the code with certain parameters. If you can tell the computer to run these, then you can become the foreman of the computer. You can just let it do the job on the background and you don't have to think about it anymore. And that's the idea of the serial job of moving from this interactive way of like, okay, I will have my IDE open. I will have my window open. I will run the code myself and run the programs myself moving towards codifying that workflow of, okay, I will choose this environment. I will choose these code pieces and I will run it with these resources and I will run these programs. That way you can easily share it with other people and you can do it non-interactively where you don't have to wait for the results just there at the screen. You don't have to wait for your computer to, like one of my friends, when he was doing one of his thesis, he basically kept his computer on all the time and it was like shouting in the next room because he needed to do the calculations. And that's not something you necessarily want to do because let's say your computer crashes and you want to use the browser or something and the computer is working on the background and it's annoying you. That's something that using non-interactive work on the cluster helps you with because you can just push it to the cluster and put it there and it will run for you those instructions that you gave it to do. Yeah. And my equivalent of your analogy is when one of my supervisors came to my office and got everyone in the group together and said, okay, I need us to run something. So you run this code with these parameters. You run it with these parameters and so on and send me all the results. So that leads exactly to our next step, which is array jobs. So should we head there? Yes. Yes, but we should move towards it. But basically try to, of course, when you're developing code and everything like that and you need the results immediately, it's usually a good idea to maybe do it on VDI or on your own laptop or anything like that on a small scale experiment to see that the code works, like the algorithm starts to move at the correct direction. But let's say you want to run the same algorithm for a longer time for bigger resources, bigger datasets, then it's a good idea to start moving towards the non-interactive use in Triton. So it's like a gradient from interactive to non-interactive. And what we're going to be talking next, the array jobs, that's basically the production ready where you want to scale your stuff up. You want to run it with big data, big number of parameters. You want to get lots of things done with minimal amount of code. Yeah, so should we go on? Yeah, let's look at the array jobs then.