 Hello. I think we should be live now. So welcome to day three of the Winter Kickstart course. So we'll resume where we left off with actually running jobs on Triton, scripting them and using parallelism of different forms and stuff like that. While we are waiting, if you can open the HackMD, you see we have an icebreaker down there. So if you can write or open it, go to edit mode and answer this reflection on parallelism. So how can your analysis be parallelized, which is sort of one of the key topics of today? Yeah, and if you feel like you don't know the answer, then that's fine as well, because, well, that's why we are here. So to help you parallelize your job, if you don't know. Exactly. I'm lost a little somewhere. So yesterday we had some problems with the Triton accounts. So some people were not able to actually run the jobs. So we think that these are fixed now. There was a problem with the authentication systems and stuff. So the user accounts were not being propagated through throughout the cluster, which is sort of unfortunate, but it happens. The cluster is such a complex thing with many different pieces all working together, connected to Alto. We're getting some reflections here. Yeah, so Seema, what do you think about today? How would you summarize what we will be discussing? Well, yeah, so I'd say the topic is like going beyond your capabilities or basically going beyond one person's like what one person and one computer can do at a time. So the idea is to do stuff non-interactively. So basically, the idea is to go beyond what you can handle at a certain time. So basically, you will be doing something non-interactively. So basically managing jobs, managing workers that do stuff for you. So basically, instead of being a worker, you will be the foreman who manages the workers and tells them where to go and what to do. And you will be the one who manages them. So this is basically the idea. It's just like everything else is just like adding the scale or doing different scales of the same kind of thing. So array jobs, parallel jobs, running GPUs, everything is just doing the same thing, but in a different scale and with different tools, but the idea is the same. You are not doing the thing interactively. You're giving instructions to the computers to do stuff non-interactively. Yeah. So what are the pieces of today? Like what are the different lessons that will go over? So first, last evening of day, I think, last day, we ran into the cliffhanger of going from non-interactive, sorry, from interactive to non-interactive. So we were running stuff already in the queue in the environment that we have in Triton. But now the thing is to do that non-interactively. So basically, to put stuff into the queue and get your workflow in such a way that you can put stuff to the queue, it will get done when it gets done, and then you can reap the rewards. And then we will do this multiple times using the array jobs. We will utilize some GPUs so that if your job needs some special accelerators, it's possible to use them. And then we'll look at other parallelization strategies that make your stuff run faster. So basically, multi-processing and MPI parallelization. So if you want to run your stuff faster with multiple processors. So that's basically the schedule today. And then I think we will try to squeeze in some final demos, someone actually running a Matlab code, someone actually running a R code, and someone actually running a Python code, like putting the whole thing together, how to combine the software and the data storage, all of these things. And make the script and whatever. Yes, we were talking about us presenters lecturing how to run some sample codes in Triton with specific software suits. So how would you say most people do their parallelism on Triton? Like what's the most common way of doing stuff? Well, the most common way is to do basically data parallelism or a parameter parallelism. So this, it's called, well, I can't recall the actual name because it's so. The single instruction multiple data or something like that? Yeah, yeah. It's more like the processor architecture, but. Yeah, and it's embarrassing. Yeah, embarrassing to not remember that. Yeah, so the idea with embarrassing parallelism is that basically you do the same thing but you switch a bit every time. So that is the easiest way. And I think a lot of our users do it annually. I myself have been guilty of this. So basically making copies of the same run scripts and running them with different parameters or something like that, making copies of the different they are doing, running the same, having a copy of the folder and doing the same kind of analysis on that. But I think there are nowadays even more ways people do parallelism and they are getting easier. So people are actually using the cluster to its fullest extent. So when you say they're getting easier, do you think it also, it's easier but still requires some special skills to do it well? I think it doesn't necessarily require special skills, but it requires this kind of a change of mind, change of work, like idea of how are you working with the machines. So it's all about organization and doing knowing your way around the machine. And that's something that sometimes can be hard. It can be technically very easy, but it can be hard to wrap your head around like what's actually happening in the system, what's actually happening with my problem. So how do I organize these different tools to work together in this kind of like a parallel fashion? And that's the hardest part usually. So of course there are other stuff that let's say MPI programming that might require a bit more special skills, but the like array programming and stuff like that is very easy. Yeah. Okay. So should we begin with the first lesson then? Yeah, I think everybody's here. Okay.