 So looking back at our plan here, we see there's three more things that look boring until we get to interesting, which is running interactive jobs. We'll talk about applications first, which is really short and sort of an introduction to how software even works on a cluster at all and why it's so difficult. Then we go to software modules, which is the common way of actually using the software and then data storage. And we hope to get to interactive jobs and maybe a little bit of serial jobs by the end of the day. So applications. So Simo, why are software on a cluster so difficult? Well, yeah, there's actually a few reasons for this. So first, some of the software needs to be installed in a very specific way for it to work in an optimized fashion. So many of the software that is available in Triton is installed by us so that it's actually working as intended. So because we want to also make certain that there's no bugs in the installation or anything like that, so that the scientific results are correct. That's pretty important when you're doing science. And the other thing is that there are a huge amount of users. So we want to support like a generic user in the best way possible. So we want to install stuff for everybody so that they can run stuff out of the box and they don't have to figure out how to install the software themselves. And they don't have to manage the installation themselves. So yeah, having self managed installations can sometimes lead to problems, especially on the storage side when you're running hundreds of thousands of jobs, then you might end up with problems in the storage side. But basically what we do in Aldous Key Comp, we install like the most commonly used software. If it's easy to install it, well, we usually install it quite quickly. If it's hard to install, then we discuss with the users how can we get it installed in the best way possible. But basically we have a lot of already existing scientific software that's been checked so that it works on our cluster. There's also of course a lot of legacy software because like we mentioned Triton is an ongoing project and it's been ongoing for years and years. So there's also legacy software for those people who have used this legacy software for their research in the years past. So you might encounter some old legacy software. We are trying to move towards a situation where we can deprecate them in a faster speed so that you won't get confused by the amount of software. But we have hundreds of different software installations in Triton. First things first, yeah. It's basically dealing with software that's difficult to install is the bane of CMOS life right now. There's so many things that can go wrong. Yeah, but the most important thing for you as a user is that you should first check our wiki page, whether the software you are looking for is available. Because if you are not a unique snowflake, if you're using some common software stack like like Bandas, Python, R, Matlab, Gpo, Lumps, TensorFlow, I don't know, PyTorch, there's a huge amount of different software that's already installed. So the software, if you look at the software in our documentation, it's not up to date. You know that at least in one point in history, we supported it. So you can ask whether we will want to install a newer version for yourself. And that's usually a good way of going. Like, when you start using some software, it's good idea to check the specific page for that software. And if the page looks old or something like that, then ask us whether we can update the software. Yeah. So when would you say someone should ask us to install software for them versus when should they try to install it themselves? That's a really good question. So I'd say that first they should check if the software is available and works for them without any modifications. So if the software is already installed, for example, we provide very, well, big Anaconda stacks for Python users, so that people can use them, we have also provide Matlab installations and stuff like that. So I haven't heard of any user who wants to install their own Matlab. I don't think it's even possible. But basically, there are many software that works out of the box and nobody needs to usually install them. Then there's questions, whether the software is very specific for your case, if you need to recompile it at some point or something, then you might want to do it yourself. If you feel that this is a software that other people in your group, in your collaborators, people want to use, or you feel like it's something that you don't know necessarily how to compile yourself, then you should ask us. But it's not like asking never hurts anybody. So it's good idea to then ask what is our opinion of a certain software if you post it. We might have also heard of alternatives. Like you might end up being recommended a software that's old and deprecated and there might be a newer software that can do the same kind of stuff. So it might be a good idea to ask us because we might have heard of a newer version of the same software or newer kind software. Yeah, that's a good point, especially about asking us. So even if you think that you definitely need to install it yourself, it doesn't hurt to ask us and say, I'm about to install this myself. Good idea, bad idea. And it might save you some time. Okay, so in the future, in the next session, we'll talk about modules, which is basically the way that you get all of the thousands of versions of software we've installed and make it usable to you. So we don't really need to talk more about that right now. We will get there shortly. One other point is singularity containers. So did you have something about the previous topic? No, no, I was just going to say about singularity containers. So basically, I don't know if you necessarily haven't heard about singularity, but it's this open source project for reusable scientific containers. So basically, they are like Docker containers, like this small, like you bunch the whole operating system and all of the software needed by your code into one file. And that file, you can then give, well, share it for the wider scientific community, you can give it to your reviewers when you submit the paper, you can put it into some archive if people want to replicate your single results. So it's like this, it's meant for reusable code. And it's also very useful if you have some software that depends on some specific versions of let's say Ubuntu 14.04 or something like that, like really old operating system, like you want to replicate some result and it's hard to install. The singularity containers are very useful for this. And we have this whole workflow built around it. And we are trying to update it so that it's even more easier for you to bring your own containers to try to. But just like if you're, if any of these sounded interesting to you, then let us know what kind of software you want to bring as a singularity container to try to we can help you deal with that. Yeah, for example, we also provide these Nvidia containers. So Nvidia has this whole scheme of they provide a huge amounts of their software, and you can run the same containers in many other systems like in in CSC and and and somewhere. So if you want to have like a like a system of identical installations on many different systems, it's my it might be a good idea to use this container so that you can scale your job to let's say CSC or somewhere else. Yeah, I always make this joke that when you have software that's so difficult to install that you just can't then you package the whole operating system and make that your software. But anyway, we already talked about requesting new software. So if you create the software that you hope others can use, please try to make it easy to package and share. And that will make it easier for others to use it. So you can see a link here where I've sort of described a little bit about that, but we don't need to go into details about that right now. So, um, we will not do these exercises right now we were talking and thought that it's not really a necessary thing to do. Um, so next we will go to software modules. Yes, I guess let's proceed. But first I propose we have a 10 minute break where everyone can get up and stretch your legs and so on. Um, Seymour, does that sound good to you? I couldn't hear you. I still can't hear you. Okay, let's go to a break. Until, well, breaks are good. So let's go until 10 past the hour. See you then.