Okay. My name is Nikolas and I’m working on a surrogate modeling replacing it expensive simulators with fast AI algorithms. And I’m Ollie. I’m a simulation engineer focused on classical methods and making those robust and automated. So at our labs, we are around 50 industry hard research software engineers and AI physics experts and we are inventing, validating, and scaling new approaches integrating AI and simulation. And we call this SI, simulation intelligence, and we have been leading this for the last 5 odd years.

1:00 So we are aiming at bridging reality with simulation by transforming industrial sectors by replacing expensive physical testing with SI software. And with this instructive to this balance, Ollie will now go through pipeline and showing how what the challenges and the solution might look like. Cool. So I’ll start by saying something I think is pretty obvious to most people here. The way in which we’re using CAE legacy tools to operate in this SI realm now is pretty different.

1:40 We’ve gone from doing maybe one or two simulations and trying to validate against that to trying to sample massive design spaces to then create learned models. And that means yeah, a few fewer manual interactions, then testing against, you know, one wind tunnel there’s now a thousand automated runs that need to be done without any interaction. We’ve also got a lot more people involved. It’s not just a CAE engineer or test engineer anymore.

2:06 We’ve got us data engineers, high-performance computing engineers, and then obviously Nicholas from the Spine team and the deep learning team there. And success has changed. As I said, we don’t want to test against one wind turbine experiment and make sure that we’re valid. We want accuracy and generalization across a whole design space, which is a you know, a lofty goal. So, what does that look like when we’re trying to design model by a single component?

2:34 The process starts very similarly to how it was being before. We want to understand the physics involved, we want to understand any simplifications we can make, and then we can pass them over to a CAE engineer like myself to set up the mesh, the boundary conditions, and then run those simulations. At that point, we’ll work with the test engineers to try and validate that case, and awesome, they’re making it work closer.

2:56 We’ve now got data generation. Let’s do this again a hundred times, a thousand times with variable parameters for the simulation. And once we’ve got data, let’s pass it to the Spine team and deep learning team to train model, learn model, foundation model, whatever you want. And now that we’ve got cheaper learned models, we can run optimizations that were previously computationally so expensive to look at. And because these models are normally differentiable, we can run gradient-based optimization for efficiency.

3:25 Adding these extra steps hasn’t really made anything simpler as it doesn’t tend to. We’ve still got all the previous negative issues. Yeah, if we have to redo a mesh because of bad quality, or if we have to get to the testing and realize that you’ve missed a critical part of physics and our solution wasn’t valid. And no matter what we do through the whole entire pipeline, whatever we make, you know, our final sort of design optimized solution, we still have to make it manufacturable, which is a bigger chunk of work.

3:50 And these extra step up problems too. You know, now the machine learning guys are exploring methods of designing safety. Maybe they realize there’s a big non-linear region that needs a chunk of data to generalize better. So, there’s a lot more going on. There are more departments, more intersections, and crucially more people involved than as we know, you know, more cooks in the kitchen doesn’t tend to go well.

4:14 Who have we got at center of this, you know, the automated pipeline? We’ve now got computational engineers, programming engineers. We’ve still got the systems engineers and the product managers defining what the system looks like. And we’ve still got people like myself, simulation engineers, working with the civic data side to come up with good solutions. I can’t store all those simulations locally, a thousand of them on my computer, so we’ve now got the data engineers.

4:37 I’ve also got Nicola on the machine learning team. The optimization engineers are now getting into parts of the product design that they previously were computationally right out of. And making sure this all works seamlessly is very critical. I don’t have time to go through all the various different ways those human encouraged human interactions can break down and fail. I think, you know, an obvious example I can think of off the top of my head was myself as a simulation engineer, not explaining this the first chunk of time being simulation concept in a CFD solution, you know, corresponding to initial condition being flat out of the main, and machine learning being running with that data and thinking it was great.

5:17 So, making sure those human interactions are, you know, kept and behaving is crucial. We also rely on some of the product management perspective purely on human interaction to feed back what’s going on at each one of these steps and intersections. This fine working with, you know, a single license on a local computer, or someone else is working on their own custom codes, some repo somewhere that the product manager doesn’t have to interact with.

5:43 So, making sure that they can see what’s going on is purely reliant on the human interaction of I mean simply scared of something like Jira or the guest. It’s not just people that can fail in this pipeline, it’s also data. Again, we don’t have time to go through all the different ways that it can go wrong. We know that simulation data that comes out of these CAE solvers, it’s not machine learning ready.

6:06 It’s in proprietary formats, it’s in formats that don’t play well together, it’s in formats that have certain metadata patched in different manners. So, making sure that we can go seamlessly from simulation to machine learning is crucial. And making sure that during that seamless transition, the provenance of the data and the original independence behind the simulation that I’ve generated isn’t being lost, that is vital. So, how do we at Pasture work and how do we make sure that all of these key components and key interactions don’t break down?

6:41 Today, we’re going to try and run through two concrete and hopefully reasonably easy to follow examples, called lighting, again, everyone’s favorite thing at the moment, and rock climbing. We’re going to go from the CAD all the way through optimization. I’m going to tell you how our simulation platform using a shared Amica space, using completely automated physics to data set pipelines, enabled by enforcing data contracts at each point of the pipeline, allows easy and explainable engineering.

7:09 So, everyone in the process can see what happened. I can see how Nicholas is using my data, making sure he isn’t doing anything particularly, you know, unhelpful with it, and he can see the original intent behind why I generated it, what simplifications I made. So, at this point, I’ll hand back over to Nicholas and I’ll introduce products. Thank you. So, I’ll go through three of our products under SI platform.

7:33 The first one here is Successor. Successor are data engines, and they orchestrate complex CAE tool change, and automates the generation of ML ready data sets. And these Yeah, and at the core of all this is our data format P types. And P types is compatible with many simulation simulators. And they feed directly directly into our AI framework. And whatever model is consuming, let’s say it’s a graph based, it’s a mesh based, or point cloud point cloud model, this works seamlessly.

8:13 Autophysics makes it possible for engineers to get access to a catalog of pre-built and plug-and-play ML and optimization workflows. So, they are composable and modular, and it’s native. That means that they are versioned, and they are extensible, and they can be reused across projects. And they they feed directly into workspaces where teams collaborate together in real time on a single source of truth. So, submodules, models, resources, they all they all synchronize in one place.

8:56 And last but not least, Tesseract. So, Tesseract is the infrastructure layer that serves everything we do. And you can think about them as Docker containers for physic software, but with differentiable programming building. So, they are easily easy to create, easy to use, and easy to share. And I will learn more about this later. Cool. So, let’s look at some case studies. So, said pumps again, I’m sorry.

9:26 Looking at pump geometry optimization, I’m going to assume you guys all know how a pump works, and the CAD model we’re going to be optimizing over is shown here. We’re going to look at some of parameters including the actual operating conditions of the pump that we’re going to train a thermal model over. If we jump into Simcenter FLOW I can open up a new workflow branch and give it some name.

9:49 And I’ve already generated my CAD model. I’ve done the parameterization. So at this point I just need to automate the export of that CAD with new parameters each step. So I can add a little CAD component into my workspace and select the CAD file that I’ve already created. This point we are going to add a design table which is going to automate the parameterization of this CAD model and that’s using Inventor here’s native vector now formats.

10:17 We can now build the regular workflow I won’t make a big deal of it by adding a ANSYS SpaceClaim preprocessor using CAD cleaner and ANSYS Fluent mesher to provide our discretization and then ANSYS Fluent solution here as well to give you a physics solver. Any one of these steps we are automating the software through their native scripting language. They have full access to the full functionality of each piece of the software.

10:39 And it’s through Momentum that you can add any hetero heterogeneous software into this pipeline. As long as there is some way of getting information from each to you know say OpenFOAM Fluent meshing in this case using OpenFOAM’s Fluent foam mesh native interface, you can pump that data all the way through abstracted away cleanly. And in that case you can easily get verified things like equivalent models between the two solutions.

11:06 You can also then very easily add multi-physics solutions in there. We could add an ANSYS Mechanical or you know Abaqus or something. In this pipeline we have the pink block at the end which Nick mentioned is our faster type conversion. We take that solution from Fluent and convert it into a machine learning ready data set all automatically before storing that and saving that. If we are happy with the workflow we can execute with some compute resource.

11:34 And then, we can see our case is running now. Jumping back to home screen, we’ve been added to our job list. And I mean, this is a real CFD solution, but it’s going to take a long time to solve. I’ll skip forward through time. It’s done. We can go and have a look at our job manager. And we can have a look at what’s left behind by this job.

11:51 It’s a In this particular case, only 16 minutes. And we can have a look at the artifacts left behind. We have everything you might expect from a CFD simulation, a few post-processing images, and then the automated logging file handled by SI assets. You know, all of this heterogeneity in background includes logging and all the sort of various automation aspects you’d expect. If you want to look at a particular post-processing image, we can.

12:16 In this case, something like cylindrical monasus convergence. We’re looking at head in this case for the burner. We can see over the 900 iterations it is converged positively, just about. So, that’s a single case. We can’t really train a target model on that. So, how do we do a thousand? If we jump back home, we can open up a new experiment file, like just like we did with the workflow file.

12:42 Give it a name. And if we select the single workflow that we’ve just created, it will automatically detect the parameters that we set up as automated in the design table. And we can create our experiments with a design table being populated by that single run we ran. At this point, we could add the rows manually if we wanted to, but I’m not going to do that for the other times.

13:01 So, doing some automatic sampling in this case, we’ll do 300 cases of, you know, Latin hypercube sampling over the parameter range that we saw earlier. We get an automatically populated design table. And when we’re happy with that, we can hit execute with some additional compute. Obviously, each one of these cases is taking about 16 minutes, so these will tag along in parallel as quickly as they can.

13:23 And we have now generated what is be a data set that I can pass off to Nicholas in the surrogate team. Now, he’s going to be working in the same work for the same thing with the intelligence platform in his own work space. And then I want to see what he’s doing with my data. So, let’s go have a look. I won’t make you sit through me building this platform or his work space.

13:43 Oh, sorry. You can visualize the local images by pressing images just like before. This is Nicholas’ work thing where he has taken in my data and I can see that he’s got a sector. I can see what he’s doing with it. He’s doing a bit of pre-processing, only grabbing certain fields because he doesn’t need all of the simulation data that’s in this faster way. And he’s pumping that directly into a surrogate model.

14:05 And we’re using in this case an automatic neural automatically chosen point cloud model and from multi-physics. He’s already trained this model, so I can have a look at what his results look like. I mean, I know nothing personally about machine learning, but my loss value and the loss graph looks plausible. I think it’s still the word. And I don’t think that the actual inferred full field results from this particular surrogate that he’s pumping in the new cadmium green, done some pre-processing to get that cadmium green in a format that can be inferred on that for running inference and getting a full field prediction that, you know, I can now look at and go, “Well, does that look plausible?

14:40 Is that a realistic full field?” It’s not just full field surrogates that we look at. We also look at quantity of interest surrogates. So, Nicholas also set up a work space where he’s pre-trained a quantity of interest surrogates which, yeah, maps the line parameters onto quantity like heads or efficiency that we want to look at. He’s pre-trained it just like he did in the previous work space and he’s running some inference on it, getting a prediction, and then running it through a custom objective function evaluation for wrapping whole entire thing in an optimizer.

15:12 The nice thing about these surrogates is they’re fully differentiable and differentiability is abstracted away through Tesla Ice. So, we can innocently but of differentiable or abstract gradient based solvers like Adam or whatever you know I thought of something to get a solution to the problem. So, it makes optimization of these things very easy and it makes them very easy for me to see how Nicholas is using my data and making sure that you know at no point is intent being lost.

15:39 But let’s take a pump example, you know, the quantity of interest surrogate is really quite cheap to evaluate but I’ve just really forced some response versus we can see that for different quantities of interest, you know, some are particularly non-linear in certain others are remarkably linear for impeller radius variation against the the pump’s operating condition at this point. Once you’ve sort of selected a particular pump geometry you’re interested in, you know, you settle on 150 mm as your radius or whatever, the quantity of interest surrogate makes it incredibly easy to generate performance curves like you might have seen in a brochure.

16:10 And we can also then go and have a look at the full field inferred model for this particular geometry setup. And we can also look at whatever other full field models or results you want. The nice thing about all of this is that we can see what was going on at each point. I can see what Nicholas is doing, he can see what I was doing. And at this point I’ll hand back to him to introduce second case study focused further on differentiability.

16:32 Thanks. Yeah, so the next example, the second case here is about how to how to optimize the stiffness of this rocket fin which is used on SpaceX rocket like this. So, basically when it re-enters the Earth, these rocket fins are used to steer the the rocket safely back to Earth. And this case study is is about showing how we can do a gradient based optimization workflow through Ansys tools that are usually not differentiable by using Tesseral driven differential programming.

17:16 And the case Yeah, the optimization problem that we are solving is this So, this is a rocket fin and the and we want to optimize or minimize the compliance by moving these these pipe there in a certain way so that the the compliance is minimized. So, there are eight in total and we will Yeah, the the optimization problem is basically just to move these around to to improve the or to minimize the compliance.

17:46 So, let’s say let’s try to just naively set up a pipeline for this. So, we have some design parameters. We have 16 So, the bars are defined by the end and the beginning and end positions. We feed that into Ansys SpaceClaim to get the surface mesh. And then this one the surface mesh is fed into the solver the PyMAPDL solver here, which is an FEM solver. It takes some additional inputs here.

18:19 And it is spit out the compliance. And we can eventually calculate the analytical endurance. And we want to optimize with regard to the design parameters, but we see a problem here that the analytical endurance is differentiable with respect to the density, but we want to optimize with with respect to the to the design parameters and they are lost because Ansys SpaceClaim is not differentiable. So, this will not work.

18:48 I mean, of course, we could do a final some final differences in the design parameters and feed that through, but that would be very expensive because the the solver is is slow. Okay, so how can we make this pipeline differentiable? We still have our our design parameters. We have the same solver. And this solver takes in for example, density field. And we can from this density field create a static mesh with boundary conditions.

19:18 And yeah, so the question is how to get this density field. So we still want to use our triangle surface mesh and from that one we can create a sign distance field and by and this is by this is field can be converted into a density field by using an elliptical function like this sigmoid function so that this shape here is different for Okay, let’s see how it looks now.

19:45 We can calculate the analytical gradients because we have a thick mesh here. The density field is differentiable with respect to the sign distance field because we have used a continuous function here the sigmoid. And yeah, so how to calculate the sign distance the derivative of the sign distance field with respect to the design parameters. So here we have used finite differences and this time is cheaper because we only need to iterate through the the the surface mesh a number of times which is much cheaper than going through the whole pipeline.

20:22 And yeah, you see here if you remember the chain rule, we have the chain rule here. Now we can get the derivative of the compliance with respect to the input parameters. So we can do that optimization using gradient descent Adam or whatever you want and now optimize or update the design parameters and do this loop again. So this is an example how we can turn a non-differentiable pipeline into differentiable pipelines and we have used Tetrix for all these components here and the very powerful features of Tetrix is that you can encapsulate the complexity of the let’s say of the inner workings of making things differentiable.

21:00 For example, the finite difference has been of course made. You have to make it differentiable but you can add back the way into these two directions and then from the caller you can just optimize and doing the reverse mode AD certain parents from the caller. We have the results. So we have done the equivalent with two initial conditions, one with a random location of the bars and one where there’s more structure.

21:28 And we see that the compliance goes down over iteration and they both converge to more or less the same. And yeah, we see that it collects the bars close to the handle where there’s a lot of most yeah, stress. And it also we also have orthogonality here. But of course this is not really useful from a manufacturing point of view and also from, you know, when steering down you need some symmetry.

21:59 So by doing a post processing step we can get to something like this and get up to 24% percentage difference than the original one. Yeah, I already I already mentioned a little bit about why we’re using set direct but just to go through it again. So one of the things that we get is composability. So now we’re using Pima PL but we could actually change it with console without any change to the pipeline.

22:26 We use space claim but you can use other measure if you want and all this is abstract into these two directions. I will talk about auto diff. About gradients of all. And also we can run some many different hardware so Windows not on yeah, in Windows and Linux with different versions. And also dependency management can be a mess so if you want to run Jax together with iPod that is already a big problem in calling these together so we You install them in different directions and the one you use model, you can you can do that as well and as part of your pipeline.

23:08 And also team collaboration, this makes it easier for teams to work together because we have we have schemas. So, input and output are defined and you can when you have a team working with another team, they know exactly what it takes and which part of the should be differentiable and what outputs. Okay. So, why I work places and this is like so powerful for engineering teams. Because no real-world engineering problem is solved by a single person or a single single tool or is is restricted to a single a single physical domain.

23:46 So, workspace is source of the problem of collaboration. So, teams can collaborate seamlessly together and with in one source one source source of truth. And the the Tesseract solves the problem of of infrastructure and and here, instead of having let’s say handing out a file and undocumented scripts, now we have oh sorry. Now we have you know, components that have natively fits into each other. And and now instead of having this fragmented world, we now have a a concise orchestrated simulation intelligence platform.

24:33 And this is exactly what we are trying to do at Pastel Labs and our promise that we are trying to to deliver. Thank you very much for listening. To learn more about the CDFAM Computational Design Symposium, access the archive of previous presentations, interviews with speakers, and information about future events around the world. Visit CDFAM.com.