 Okay, so hi everyone, my name is Alan Akash. I worked at Uliq's Supercomputing Center for about 10 years now actually, and I mostly worked in one of the EU HPC centers of excellence, but I did have, well, I was the one who brought Easy Build to Uliq, and I also was responsible for the big machines there when it was initially installed four or five years ago. And now Easy Build is used across all the resources in Uliq. So Uliq itself, it's a pretty large supercomputing center and it's around since about 1987. It has, when I started, there was just over 100 people working at Uliq, but it's doubled in size in the last 10 years. So we now have about 200 people who do everything across the range of activities in supercomputing and simulation sciences. And that includes these days quantum computing as well and lots of stuff for the AI and things like that as well. And we have at the moment three primary systems. So our big system is called Joules. It's based on this concept of modular supercomputing architectures so that you have a different part of the systems with potentially different architectures and different capabilities. And the system at the moment is, I think it's 12 pedoflops and that'll be increased this year to 70 pedoflops because we're about to get an NVIDIA Ampere GPU booster partition, which is about 58 pedoflops and that's due to be delivered before the end of this year. So we'd be the first, I think in the official announcement we're the first supercomputing center to get the Ampere GPUs, especially at that size. That should make Joules the biggest public supercomputer in Europe then. And the next, one of the other systems that we have which is the one I was originally involved with setting up with Easybook that's Eureka. So that's also a modular supercomputing architecture. So it has CPU partitions, it has GPU partition and it also has night's landing as well. So it has the largest part of the flops comes from the night's landing partition as well. And that's actually due to be replaced this year as well. So there's a lot of activity in terms of hardware going on in the new week this year. So largely dismantled and replaced them with kind of a lot of data-centric hardware. The final thing is something called USIF. It's an AMD machine with quite a few V100 NVIDIA GPUs as well. This machine is targeted towards particular workloads. So interactive workflow and then a lot of community-based web services that require HPC resources as well. That's the main target for that system. In terms of how we use Easybook at JSE, well, we've been using it for a while. And so I think Kenneth mentioned that like the first public release was in 2012 and we were already coordinating a workshop on Easybook by, I think it was in early, early 2013. And the way we use it on our system is, of course we have a lot of different users. We have a lot of different systems and the users have a lot of different capabilities. So the general usage is target towards the average user experience. And so what that means for us is that we hide a lot of indirect software. Software that the user typically might not necessarily want in a normal workflow. So they might be interested in Gromax but not all of the dependencies of Gromax. So we might hide a lot of these indirect dependencies that people might have. We also have a lot of tool chains because we have these different kinds of hardware on the same machine that tends to require different compilers. So for example, if you wanna use OpenACC on a Eureka machine, then you're probably gonna need the Portland Group compiler. And we also have different MPIs and because you wanna make sure that you're CUDA aware MPIs available for the CUDA partitions but also we also have custom MPIs that are geared towards the CPU partition of the machine as well. So in general, this leads to proliferation of tool chains. And because we have lots of tool chains then a module hierarchy makes a lot of sense for us. And so that we make sure that what people get is actually compatible and when they try and run their code. And we also rename some modules to try and make it easier for people as well. So for example, as an example instead of calling the Intel MPI implementation the software name is IMPI but we rename it to Intel MPI. In Easy Build, the Intel compilers are called ECCI Fort. We rename those to just call them Intel. And there's a couple of other cases like that but they're not so many but the idea is just to make it some names we just tweak them a little bit to try and make it easier for our users. We also do a couple of Elmod tweaks as well just adding some tags to different modules and also changing the way Elmod looks a little bit to the end user as well just try and make everything as straightforward as possible. And we have lots of customizations. We've been using Easy Build since 2012 and it's kind of a little bit as a result of that. So we use our own custom module naming scheme which is very heavily related to the module hierarchy but has some slight customizations on top of that. We have lots of custom tool chains that we use because we have our own combinations of various things we maintain our own easy config stack. And that's because our update cycle is not exactly in sync with Easy Build and our tool chains are not exactly the same as the ones that are used in the distributed and easy configs of Easy Build. So we have until now maintained our own set of easy configs and we also have custom easy blocks. So we don't have too many of those but we do have some for things we do ourselves. And in terms of the impact of this, I think really it becomes a little bit of a maintenance thing. So it means that we actually have to carry out quite a bit of maintenance and it also inhibits our ability to contribute back. So if we're using custom easy blocks and our custom easy and configs and custom tool chains it makes it a bit convoluted for us to contribute back to the main repos especially because our update cycle is slightly out. So in terms of things like our dependencies the versions might not be exactly the same main repo. So that makes things hard. And we're working pretty hard to try and remove this at the moment. So as much as possible, we actually wanna align ourselves with Easy Build and just use customizations in other ways. In terms of how we present software to the users, so we get new users twice a year and when new users come on our machine we only want them to see the latest versions of the software. So we actually have what's called a stages concept. So whenever new people come on the machine they see a stage which is the latest versions of our tool chains with the latest versions of the software available in those tool chains. And this gets updated twice a year. So the production view that people see gets updated twice a year. And the idea behind this is that it encourages people to adopt the latest software and all the dependencies and that should lead to hopefully better performance and people not running into bugs that were there in previous versions. Of course, we make it possible so that people can still use all software, right? So it just becomes, there's a step involved in them getting access to previously installed software. But by default, we wanna push people to the latest versions of software all the time and we do that twice a year. So yeah, we give indirect access to the retired software. So there's a step involved that they need to do. And this also has an impact on module spider as well. So because of the way we present software when somebody is a module spider they by default will only look in the current stage. And but if they do use it an additional simple module use statements then they'll actually have access to all of the software and including all the legacy software. And as you can imagine after a few years running for four to five years now there's a lot of that. There's a lot of old software there. So again, the idea of the stages is to keep the view for the average user quite clean and not overpower them with lots of different software versions and things like that. And what we're looking at now which is like relatively recent in EasyBuild is this idea of hooks. So being able to hook into various steps that along the way when EasyBuild is building software and we wanna use that both for our maintainers and for our users as well. So we see this as a pretty powerful alternative to doing the customizations. And this is our way of backing out of the maintenance problem that we have and trying to just instead create some pretty powerful hooks and then use them to have an... Well, we see them as much more automated. So they can be clever. They can have logic inside and that makes them a lot more flexible as well. And for us then it will be easier to maintain in the future. So for example, one of the reasons we maintain our own easy configs is that we actually want to insert things like a site context. So the person that's responsible for a particular software package. The moment that's requiring us to maintain our own easy configs but we could actually do that with a hook and that would be quite easy to do in a hook. So that's one of the reasons we use those. And the other thing we wanna do is that we wanna enable user space installations. And that's a little bit tricky because you could say that there's a right way to do this. So for example, you've heard a little bit now about GCC Core. And so the tool chain GCC Core usually has a lot of dependencies in there that maybe users don't really care about. But it means that if they want to use their own GCC Core it usually pulls in a lot of additional software dependency for them because it would require something else. So a hook is a way to actually tell them don't do that. Instead of doing that, use some of the tricks that some of the stuff that's in there the tweaks that are available in EasyBuild. So instead of using, trying to build a new GCC use instead try tool chain on your fingers. And I can also tell you, you can tell people how to resolve dependencies or how to use the soft easy configs that are available in the JSC repo. And basically there's lots of little things that you can do to make the user experience a little bit more straightforward. And a little bit, and a lot more compatible with how we deliver our software. And I think, yeah, I think that's it for me. That's all I wanted to say. But maybe somebody has any questions.