 I think probably most of you know, one or both of us, I'm Kyle, this is Adam, we're the biocast of the Zedmonds here, and it's just got to go over kind of a quick primer for those of you who don't know what a biocat is, and maybe some information about it you didn't know. There's been some confusion lately, it sounds like some people seem to think that, you know, it's kind of the wild west, it's kind of maybe you build your own, no support, that kind of thing. So here to clarify some of that and kind of give you some information about what a biocat is and how it might help you out. First things first, high performance computing in general, or as we see it, what we call it, and what is that? It's really a whole bunch of computers working together as one large computer or in some cases, you know, we'll have clusters of these 24 machines that work on one project, and these 10 will work another, and these other ones will be working on individual ones or maybe even sort of double piece, that kind of thing. They're made to run, we're using a protocol called MPI, which is letting us park between machines as well as inside machines to run things parallel versus serial. One thing we emphasize is that if you, especially if you're running serial codes, if your software isn't specifically designed to take care of one-on-one core, running my HPC won't make your code run faster. Now, that doesn't mean that it's still no good because if your serial code is running for three weeks on your laptop and you can't use it for three weeks, you still might want to upload it somewhere else, we're still good in those cases, but that's not what our focus is, but we still have some use even in there. But just so you know, you run over on a big machine, it doesn't necessarily mean it's going to run faster. 95% or so run Linux, ours runs Linux, and that's as opposed to Unix, the previous team, some of those other strange things. Nobody runs Windows, Microsoft, Pride, an HPC initiative 10-ish years ago and it pretty well flopped. So nobody's really doing HPC on anything besides Unix-like platforms. Is that a supercomputer in the top 500 is running this? No, there's like three of them that aren't. I think there's two of them that are running VSD and one I'm running with Rydery Unix, I don't remember, so it's pretty close to me. As with any scarce resource, we have to have a technical way of assigning resources to people, and we have it through a scheduler. So as opposed to your desktop where you tell it to, I want to start working on this problem, use it into a scheduler, it says, I can fit you in at this date, this time, and let's it run then. And it's constantly going through ejaculations as people with higher priority come in, then get you back a little bit, as machine die, as jobs get done early, early than they expected, things like that. So they're always doing these re-computations so they can make the most efficient use of the resources that we have. And it is research-grade. I like to claim that we have a solid 95 as an uptime. We really do shoot for about 95% of time, but we are not shooting for the super uptime like we do on the central IT. We don't have all the redundancy built in, and I appreciate the job that they do because I like getting my check every Friday. And so, but we're not that. We are not trying to be super duper reliable. We spend our money on making it go as fast as we can while we can. So that's kind of the difference between us and what you might think of as your typical IG stuff. It's full statistics here, just from where we are as of right now. And this is, yep, everything is up and going, which very rarely is all of it going up and going at once because when you're running this many machines, things happen, especially when they start getting old. We have some that are five, six, seven years old now at this point. I think, very, anyway, we have 339 nodes. It's a little over 200 cores in there. RAM, 43 terabytes of RAM among those. That's really kind of case states niche when you compare us to our peer institutions. The number of cores we have, the number of nodes we have is a little bit lower than some of those, but the number of RAM we have is higher. That's just due to the nature of the problems that we tend to be solving right now, the biggest drivers of that tend to be chemistry and DNA sequencing through plant pathology and some other places that are doing DNA type things. We have a little over three petabytes, broad disk space in our main cluster. We have another half petabyte or more in the secondary cluster. That's raw space. We do, I say we're, research grade doesn't mean we have no redundancy. We are running normal replications and that kind of thing. So one of our 500 disks goes out and we're not losing everything, which makes sense. We do have 102 GPUs that cost us about $370,000, two quarters in there. That's, we are running desktop quality GPUs, our stuff, just because they're single precision, employee point is about equivalent as the bigger machines that cost 10 times as much and most of our codes run single precision. So for what we need to do, that works out pretty well. Our biggest nodes that we have, this one's actually, this is the oldest one I'm talking about. I think it's about seven years old, six, seven years old in there. It's got 80 cores and a terabyte of RAM. I like pulling this up when people have not seen machines being used in an HVC environment before. I'll pull up one of the machines and show them H-top on it, because you'll see 80 cores running flat out 100% CPU utilization almost all the time. And it's kind of impressive to see that many just like pay. And it has a terabyte of RAM. So even though it's older and the CPU is a little over on that one, it has plenty of RAMs that makes it useful. We do have a couple of machines that have 32 spally cores of the newest ones and a terabyte and a half of RAM and some GPUs in there too. So we don't have a lot in that range because those are obviously really expensive machines. We start from that much RAM in a box, but we do have those. That's the big end, the small end. We have several of these, these 16 standard-grange cores with 64 gigs of RAM and with even small RAM, 20 Broadwell is the next previous generation with 32 gigs of RAM. So still fairly decent size even on the small RAM, but pretty impressive when you get to the bigger end of machines. We're funded. Everything is supported by grants with the exception of a couple of socially funded salaried lights including mine, which I appreciate. Thanks guys. Everything else is provided for by our supporters. So this is people's buying machines for us. And I'll talk about that in just a second. It is free for use for any researcher in the state and their collaborators. And yes, that really means free. Anybody here on campus, if you have some computing time, these would be used. You can sign up and you can use it for free. Now, if you're running on the free tier, you also get pushed to the back of the line. So that's the trick is that, sometimes especially if you're running in small jobs, a lot of times you can even run just as well if you would if you don't know. But so what we do is we have people buy us machines. And the deal with that is that then if you buy a machine, you have priority access on that machine. So if anybody outside of your working group is on that machine and you need to use it, it kicks them off. That'd be the free people on the free tier. It kicks them off and then you get priority access on it. Typical work cycle of a research machine is people work on it really heavily for somewhere from one to three months and then it'll sit doing nothing for another one to three months. Sometimes that process is faster, sometimes it's slower. But that's fairly typical for a research, a particular researcher. So they'll have it really, their machines will be really busy for a while and then they'll go idling. They won't be using it for a while, whether while they're doing their own analysis and that kind of things or offline work. And that's when the people on the free tier can jump on there and use their machines for free. So that's kind of how we fund this whole thing and how we can make it free for any research in the state. And it is a researcher in the state. We do have people from other universities, Kuporia, Fort Hayes, Benedictine even has one. And one of my personal points of pride is that we've had a couple of people from K-Event Center used our machine because it's easier to get it down on our machine than it was to get on K-Use machine. Our supporters tend to be people who have run their own clusters in the past. You guys are IT pros so you probably understand this pretty well. But people find out that the expensive part about running a machine is not buying hardware. It's keeping the security patches. It's keeping software updated and all this kind of thing. You don't want turnover. So people would buy a cluster in the past and be a six-node cluster or something small like that and they'd have to put a grad student on it. And then the grad student would graduate and the six-node students say, I can't walk in anymore. What do I do? And they don't know. So those tend to be our biggest supporters or people who have had their own clusters in the past. And more recently, Central has been pushing people toward us whenever people talking about buying with startup funds, that kind of thing. So we have a wider variety now than we did when I started here 60 years ago. Why this matter to you? Okay, we support your researchers. We do have two full-time system administrators. We have a full-time application scientist. We call him our user optimizer. Sometimes he optimizes codes, sometimes he just optimizes the users. And that really gets into some of the finer points using the system as effectively as possible. And he is there full-time. He'll, it's not unusual to come by an afternoon and he'll be sitting down with somebody I've never met before, either rewriting code or figuring out the best way and you'll figure out how to best scale it or scale it really well up to one machine, but not on multiples or just scale it really well to eight machines. But once you put the knife on there, the performance really slowed down. He's really good about that. And we do have another person on staff. He's working specifically with the CNAP project. That was a $10 million grant, $8 million grant, something like that that was announced last year is with the psychology department, I believe. Anyway, they're kind of separate. They kind of work with us, but not really, but we do have somebody actually working full-time on that. Why this matter to you? Because we are a free resource that you should be aware of. We are here to help you guys out. As far as the research side of things, we don't do anything on the academic side of the house. We don't do anything production side of the house. But on the research side, we can help you out. And hey, we can offload some of your work. Isn't that a good thing? We want to be there. We are in a good spot to be helping those people out, whereas you might have limited knowledge in that particular area. So especially when it comes to Linux and that type of thing, people who don't work with Linux tend to know nothing about it. And people who work with it tend to know a lot about it. So we can help you out with that. My boss, Danny Driesen, also teaches a class every fall. It's CS625. It's parallel computing. Something's good, parallel programming. That's a big point, parallel programming. Actually, we usually call it 625 because computer guys don't do that. But anyway, he is constantly putting out calls for people who need better code. So all the students in that class have a project they have to do where they're optimizing code and they're optimizing best ways. We had somebody actually got an A in the classes last year by reading documentation. Seriously, it was like, okay, we're gonna have to rewrite this and make it better. And they went to the documentation. Oh, it's already done that. We just need to invoke it the right way. They got off really easy, but sometimes that's what it takes. You know, it's a matter of understanding what's going on. The people running it didn't understand what was going on and they got a significant speed up from reading the documentation and using it correctly. And that's okay. And so if you have even just like one or two people that are needing stuff going faster, that is a resource that you can use. Here's some examples. We decided not to put names on here. So the veterans were reporting this and we're gonna put this on our YouTube channel and I don't wanna call anybody off that kind of thing. But we had somebody in the specific department. They were using R. And they had jobs that were running in the two to three week range. And they were running a couple hundred thousand of them in that two to three week range and it was taking a while. Dave, our application scientist, the user optimization guy, he rewrote it in C and that gave it 10 times speed up. And then he parallelized it some in C and that gave it another five times speed up. So he had another 50 times speed up. So now instead of running in two to three weeks, he was running in a couple of hours. That makes a huge difference when your researchers are getting things done. And when they can start doing that, especially when you're talking to that volume of jobs they're doing. One of my favorite stories, this was like one of those 625 projects I was just talking about student worked on that one. You can see the number in there. It's pretty impressive. We had a researcher come to us and met and saying, we have things going, but it's working, but it's really slow. Now, usually when we hear things really slow, we typically think of something in the weeks, maybe a couple of weeks, maybe a month kind of range. And so Dan, my boss goes to her and says, okay, so how long is it taking you down? Well, from what it's done so far and how many we have to go, we think it's going to take about 150 years. Obviously that's not tenable. So he threw this at a student group and they got an 18 million time speed up, got it down to a few minutes. Brown something that was taken in the hour, just from being inefficient in the way it was being coded and taking over some of those kinds of things. We have some non-commissioned things we've done too because we have a lot of hardware out there. We work with Econ here this last year. They have a Windows Matlab server in their office and their own server was dying. And they were wanting to move things to diverse infrastructure. And from this, they needed several quarters and 64 gigs of RAM and central P to us saying, we don't have any machines that have 64 gigs of RAM or gigs of RAM that we can throw at this. And so we worked with Central and with the group. We created a virtual machine, a Windows machine that they are actually running all the security and that kind of thing. So we don't have to go outside of our expertise. We have Central doing that, but we're throwing the hardware at it because that research grade is good enough for what they were working on there. And we can throw a lot of hardware at it real quick and so we can make them happy, kept IT happy, he said it was IT happy because they weren't having to use a lot of their resources on something that was being used in a research and non-critical role like that. Mechanical engineering. We had somebody who was what, six months ago maybe? Yeah, that was six months ago. That their job kept using more and more RAM as they were trying to do it. We had somebody work on it and figured out where things were going on this reprogramming and got that down from running over 75 gigs per job to down to less than one gig per hour. It was a MATLAB application. They had actually compiled it down to a binary that you could use as well, as we do without MATLAB. And we think that the MATLAB garbage collection was not collecting fast enough. And so it would easily hit 75 to 150, somewhere in there, gigs of memory and he just rewrote that and see and it runs in less time and way, way, way less memory. Another one, this just happened this week. So this is brand new and we had a PhD student in physics that had a Python program and Adam sat down with him and was just yesterday. Yeah, two days ago. Two days ago. These jobs were running, again, looking like it was going to take several weeks. And by figuring out how this thing was running and how we could optimize it, he got that finished at the afternoon that he came in to visit with us after using a significant portion of our cluster resources for a couple of weeks, sat down with us and got that down to a very short time period he was done that afternoon. So, so we do work with people, you know, we have on the programming in, on the use in that kind of thing. Those are what we really do well at. And in the other side of things. Other resources that we can help with, we have a MATLAB compilation license and MATLAB is a big thing across campus. We can't run MATLAB, we actually, we can run MATLAB directly on our cluster but we don't provide any license. So you have to provide your own license server and people don't tend to like that because they don't know when the job's going to start so they don't want to be off of their own license and that kind of thing. But we do have a MATLAB compiler license. So it'll actually take MATLAB and create C. This is a, this is a math works project. This is not anything we've done. This is them, they have this. And so you compile it one time and then you can submit that job without actually running MATLAB, you're just running their C code onto our cluster. So that's one thing we do. We have exceed resources. That is, if things get too big for you but us, we've only had it happen a couple of times but you have people that need a whole lot of processing power. We have contacts around the nation exceeding the national resource, running on computers in Pittsburgh, in San Diego and Austin, Texas. Some of the bigger supercomputers in the world actually and help us get those jobs out of there even if we need to get to that site. On the other end of that, we have open science grid. Open science grid is for high throughput competing where you might have a smaller job, doesn't require a lot of resources. What you're doing it millions of times potentially or hundreds of thousands of times. So you're doing my carless simulations, those types of things that, you know, they don't take a lot of resources individually but together they can get a lot. So we remember open science grid, you can submit your jobs out there and it'll be distributed nationwide. So you might have a couple of jobs right here at K-State, you might have some in Nebraska, you might have some in Chicago, you might have some elsewhere but instead of running all on one spot, it's distributed nationwide and we can help you get on to that. And this is new actually just this week, we actually got it running. GPN is a Great Plains Network that is a consortium of states in this area, us, Oklahoma, Arkansas, Missouri, what's that? Minnesota, yeah, South Dakota, North Dakota, yeah, kind of the Midwest region. That's a group of states that are working together on a bunch of projects and we now have a Kubernetes cluster distributed there too. So we need some Docker and containerized stuff. We have ways we can go there, like I said, that's very highly experimental right now but if you have something that fits in that project space, let us know, I'll be out with you. Yeah, that's it, we've got a meeting.