Mattai Montanari – Scientific Computing and Engineering Design Accelerated by CI/CD

By its very nature, High-Performance Computing requires that code is extensively tested and it's extremely reliable and that any changes do not introduce vulnerabilities or risk into the project. Dr Mattia Montanari of Oxford University will talk to us about scientific computing and engineering design accelerated by CI/CD. And using CI/CD as the enabler for large scale High-Performance Computing Projects.

Welcome to do a session about scientific computing and engineering design accelerated by continuous integration and continuous deployment, scientific computing and engineering design is what enable engineers to make history and engineers make history when they build things, when they build the buildings, the fastest report in this century. Engineers need to have computer simulations at their hands and certainly the recent astronaut that flew back and forth. Our planet did use benefit some of this technology to compete.

Different computing and engineering design is what I've been working on for over 10 years now, and it's a combination of topics that have really find interesting and still fascinating and material denarii. And I'm a postdoctoral researcher at the University of Oxford at Oxford. We committed to create better simulation tools for our clients and sponsors.

What is better? What does that mean? Well, we mean better value.

And in particular, we have to show that the impact that our research does on their workflow and daily basis happens very quickly. So we need to accelerate that. And obviously, I'm here to talk about how we accelerated that deliverable with continuous integration.

But the steps on identifying Getler as a key enabler for it are not quite straightforward. So I'll talk it through the story and give you a little bit of complex context, specifically on which problems we solved with GitLab. And the hope is that you can apply the solutions we design straight away, or you can use this recipe to come up with your own solution.

So about the problem we need to solve. He is a little bit of context in our research lab. What we do is to develop a software and in front of you you've got the history of commit.

And since January 2001 and as you see, if you are a software developer, you might see that this is a rather bumpy road, looks like a roller coaster, pretty much representing the fun we've got in our lab. The truth is that in a research team like ours, there is no smooth development by the nature of our job because we need to go back to the whiteboard, design the math implemented, and then spend time writing papers and publishing at conferences. And all the time that is taken away from software development also create challenges for the software development itself, because we tend to lose a lot of information in the process.

If you are a fan of GitHub, you know what I'm going to say. And when I talk about keeping all informations into one place. So I started approaching the club about 10 years ago, seven years ago, immediately after I joined Oxford, because we had some specific problems.

But at that time, our software development stack was rather simple. We had literally one idea, one compiler debugger and version control system, which wasn't even git. And we had the problem of knowledge transfer and the development in the over the years.

When I did look at possible solutions online, I found various ones, particularly Git and Getler. So I migrate to get and I adopted Getler kind of early and despite their initial logo, get Leopardi and developed a delivered a much better logo. But that's not the main reason why we're still using GitHub.

The reason one is because of the capabilities that Getler carries. To give you a little bit more, to go a little bit deeper in what was the problem that we needed to resolve? I'm going to take you a few years back.

And it was the time when in that particular time frame, when a senior member of the team left and I was just about to pick up C and the software architecture and the math, and it was very little overlap. These overlap reflect the lack of productivity. And that's what the challenge challenges on my end.

And I wish that that person went left, had left more informations behind. When one was gone, everything was gone. And so through GitLab, over the years, we managed to improve on that front and I believe quite a lot.

So that's hopefully a solution that you can improve and can adopt to improve your workflow as well. But there was also not a key aspect that I didn't consider initially would get one particular with continuous integration. Really, what we managed to improve was the documentation documenting code, not just written documentation, but also how to use the code and how to develop the code, because with the continuous integration, you need to have a pipeline that is always a lot.

I've always been up to date. That's how we convey information on how to use the code. And we and did that, bringing more and more tools into development itself, the development stack.

And we've got a rather large self-test back just over a few years. Most of these tools, I implemented them really just to have a more moderate software development stack and a more and performant pipeline and being able to create documentation, the test and so on and so forth, and also supporting different platform. Now, there was a very good result, and infrastructure we built is now underpinning a project called Asimov, I see movies of really challenging problem because it's enabling.

It's about simulating a whole engine model, the whole engine, and is an extremely complex system that takes more than five to 10, takes about five to 10 years to be built. And the physics that happen, the combustion and the and the fluid dynamics happening all within the engine are extremely challenging. So Asimov project has got something to do with science fiction, really, because all this problem is we don't know how to solve them yet and we have to do all this modelling from scratch.

So the way we develop our methods starts from a whiteboard. Then we'd run prototype codes, serial code on scripting languages. Ultimately, we have to run on HPC system systems as high performance computing systems.

Why do we do all of this? Why? Simulations are important because simulations enable engineers to predict the future.

And if an engineer can predict how a component will behave, it can help them preventing. Problems like this, as you see in this picture, how part of the engine is missing. It just disassembled and it wasn't terribly nice flight experience for the passenger sitting just over the wings.

So simulations are important. And stimulating a whole engine is a challenge nobody has managed to achieve and to complete yet. Now.

I'll use this example, Ashimov in particular, to illustrate through the pipeline that I built that supports project like Ashimov, but we also support a project in parallel to it. And after assembly is completed as well, the pipeline we build needed to be simple because of the physics of the problem we want to solve are complicated enough. We need we didn't need to have extra complexity in the workflow.

So the pipeline we built is linear and very simple and yet has to be flexible to accommodate different projects and particular communication with external partners. And here is how it looks. These are simple, five simple steps.

Build, test run, run and publish. These are continuous integration stages, not all of this are required, only publish is always required. And that's because the nature of our work as researchers, we need to publish where the outside to the world through conferences or just publish results to decline.

So that needs to happen. Everything else will be included if needed. For those of you who are new to continuous integration, the very first thing you need to do, at least my recommendation would be to start from a very simple pipeline.

I and put this in the root of your project folder. Again, those more experienced with GitHub will know what I'm talking about, but everybody else just please follow along because it's really simple to get your pipeline to work. This file will begin with an image which essentially specifies which virtual machine you want your jobs to run on.

And this is a delicate image and you can create your own you can download some from the Internet for free and is a very flexible environment. And the key here is that through docker and virtual machines, what we can do is to close that gap between the early stage development of the math that we do in the lab and the production environment, the HPC. So the supercomputer environment.

It was a big opportunity for us to translate the preliminary code we tested in our workstation and then translate into something that could be operational on a supercomputer now because the Getler pipeline mimics the production environment. Effectively, what we can do is to bring that production environment during development environment, during the development stage in our research labs. So I think that was a key and enabler that closed the gaps.

Then what we're going to do is to lease the stages I've got into the five stages. But for the sake argument, in this example, I'm just using three published this list, this define which stage I want to run, but also the order. So I'm going to have three jobs.

The first one is when I'm going to create documentation. So it's cold that docks built. It's a build stage and the script can be whatever you want.

The second and a third job are run and probably stages called soul and pages. That's all I need to do to appreciate. Before I could take you to the next five examples where I'll illustrate this pipeline in more and more complex examples, ideally where you will find useful information.

So let's go ahead and kick off with the very first example, which is about creating a public static website. This example is taken from GitLab documentation and the website. We're going to build a preview at the bottom left.

I script. As you see, we have to specify an image. This image was was provided by Tim.

And so if you don't know enough about document and compiling an image, you don't have to worry about. There are plenty of examples for you to grab and to learn from. The only stage I'm going to use out of the five I listed here in the center is published.

I could have made this statement. But again, I think it's good practice to have that. And so the two state deal, two jobs in the state's publish our development and in this state, what happens is that Hugo simply builds the website and that enables you to preview the website and then go through a review process.

And once you're happy with the changes, you can then close the branch through my request and move on onto the next stage, which again builds the website, but also publishes the website. So the pipeline we build is five simple steps, very linear, but also flexible enough to accommodate and workflows in which you need to have a collaboration. So that has to be.

Let's now have a look at another example. This is, again, about creating a website, but this website will contain simulation results. So what needs to happen in the pipeline is first we need to run a simulation.

We need to extract some results and then publish them online. You'll see the source code, for example, online. And is essentially lecture notes that helped me teaching FBM, which is finite element method to students.

So the two stages we're going to run are run and publish in the run. We do a couple of things. First of all, we install.

The Python dependencies then run in the script phase, we run the simulation and the artifacts session, what we do effectively is to take the output of that simulation and store it somewhere on a cloud. In the pages of what happens is that we stole a few more dependencies and we don't rerun the simulation, we just take the results and we create a pipeline and we create a website with them. This doesn't just enable us to create lecture notes more quickly, correct them in a timely manner, but also enables students to learn how to run simulations, enable students to understand what and what dependencies simulation need to have.

So setting the development environment will be more transparent from the very beginning and again in case of much larger projects. It could be the very same environment as in production. And this is something we didn't consider about getting up and about the CIA pipeline in general, and I find it really handy.

Now, let's build a little bit more complexity with the next example. This is about my own research, which I created, a library was implemented in a city that calculates distances between two or three objects because they see we need to build an executable and because the software is rather complicated, we need to have all sort of test unit test application tests and so on. Then we need to run a simulation, take the results process then.

And moved them online or in a report, in pictures, for papers, so on and so forth, so effectively we need to publish this script for this project is a little bit more complicated. And so I didn't want to put this the whole script here, but I think it's. It's obvious that this pipeline will accumulate more complex projects and there's also another thing.

I and give club. What we managed to do was keep private some information that we didn't want to disclose and disclose, information that we could disclose. And there's recently another improvement I made to this pipeline.

I managed to add a rendering step that is basically rendering a 3D object from dissimulation results. And in fact, if you now see the website, if you visit the website that I'm linking here, you can see that there is a hand moving left and right on the green cube. And that means you can drag and drop, but you can drag that tube and interact with it.

And so this gave us enough confidence that this pipeline would be flexible enough and strong enough to support projects like Ashimov and the development of the software of the whole thing. Now, I'm going to assume what we need to do ultimately is to make some work that was done by the Virginia Tech guys, which is a simulation in which, for example, here you got a drone that impacts the blades of a turbine engine. And on the fragmentation spoliation damage that happens in the engine needs to be accurate to high fidelity.

And that means includes various physics and having a performance code. What we need to do is not to model just different parts of the engine, but to model the whole engine. So we get a great deal of challenges here.

But I believe it is going to be really good fun and it's going to be a very productive project in which we can learn quite a lot. And because we want to track every single change we make in the code and we want to test it and we want to be transparent, well, then we need to have a site pipeline in place. Before I conclude my talk, I would like to leave you with two notes, two reasons why I trust GitLab.

The first one is because of transparency. Very early when I looked for various providers and solutions, I really like what's in their DNA, which is transparency, fun enough. You see that happening actually in the very first GitLab issue.

Issue number one is about updating some licenses and updating terms and conditions. And they also have another thing. The handbook some of you may know the digital handbook is the recipe, how GitLab operates and regardless of which stage you are in your career, I think you can go and have a look at the handbook provided by GitLab, and I believe you can find something to learn.

I've certainly learned a lot from GitLab's Handbook. The second note is about security. Again, funding enough.

Issue number two is about GitLab security. But third examples I just showed. I hope you've got good confidence that the security and the flexibility of the platform enable all to have a secure workflow and secure pipeline.

Some of that pipeline is obviously well documented in the manual. You can talk to people, you can read through blogs, but ultimately what you really need to do is to get your hands dirty. This concludes my talk.

I hope you find it useful. If you do have any questions, please don't hesitate to get in touch. Thank you very much for listening.