Running. Cool. So, since starting Pasteur Labs almost 5 years ago now, I’ve had this same slide kind of kicking off most of the decks. Nothing surprising for the audience here. Simulators are not living up to what most people expect out of simulation. There’s this idea or misconception about digital physical parody. We would love that out of our software but the legacy simulation software stack obviously does not deliver in many ways.

0:36 Passor Lab started because we know the precise bottlenecks. The bottlenecks are the core computing like methods underlying the software simulation tools that many of us use today have been using for decades. And these tools ultimately constrain how engineers and companies rely or rather like don’t rely on simulation. So at Pastor we’re about 40 industry hardened experts in many domains. Our work is inventing validating testing scaling these new approaches to integrating AI and simulation.

1:12 And especially in the field or broad scope of engineering physics that’s roughly what we refer to as simulation intelligence. Now in other presentations there have been many of these cool intriguing demos on physics AI. There’s been animated vector fields user friendly front ends these streamlines in wind tunnels etc. Don’t get it twisted. We definitely have those. This is a a GIF of a user in what we call autophysics, our main product in an autophysics workspace kicking off a data generation engine that they will eventually use in some simulation workflow.

Here is some early results in collaboration with NTOP where you can see many solutions like this come pre-built with our SI platform the simulation intelligence platform in that autophysics catalog. So you can start with template solutions that run end to end from design and concept all the way to manufacturability for broadly inverse engineering and many different objectives. Check out the talk last year. This was the centerpiece of it and it is all about how we did the hard engineering to wrangle all the different CAE tools and well lack of interfaces.

2:43 So then you aren’t doing the glue code or stitching together of I don’t know like I don’t know seamanx and maybe inventor with some answers workbench thing and maybe you’re still using a space claim and tried pianis but why and you’re jumping between gies u and it takes you weeks when really this just runs headless distributed at scale and it pumps out ML ready data sets most people don’t even know what that is before they run into that problem.

3:18 This paper went live today. Yeah, we have a plasma physics team. We have some big bets in nuclear energy fusion and fision. And so being able to move as many physical expensive physical tests from the real world into simulation. The biggest impact there we believe will be infusion. That’s really what we’re trying to bring to many sectors and all our customers. So, those fun visuals aside, I’m not here to sell or hype up physics as AI with a few demos, especially not demos of, I don’t know, cars in wind tunnels in nominal settings that just kind of stay there and drive straight because that’s how cars in the real world obviously work.

4:00 I want to describe why we care about physics programs or when well I say but like my team says and you’ll see with our products coming out like what we mean by the IDE for reality. So, taking a step back, this highdimensional simulation space is kind of like why we’re all here and like figuring out cool useful ways to navigate that space. So, bear with me. It’s not perfect analogies or maths but in this broad space of simulations one particular simulation it’s like a CE setup or a numerical numerical codes is a vector to a point in the highdimensional simulation space let’s call it a vector because there’s an origin that origin is specified by some physics well specs parameters it’s grounded in physics like the way you would set up u a CFD simulation Surrogate models are cool.

5:06 We do a lot of them. Surrogate models try to predict points in the simulation space by mimicking that simulation vector. It’s a function that outputs independent point predictions around that vector point in the simulation space. Clearly those those red marks. It can be really useful for say replacing your CFD simulation with like a faster well accelerated version or maybe using a surrogate to predict some performance characteristics of a reference design.

5:39 What well we at Pastor and I would bet and I have that most of you are really interested in is this solution surface this blue amorphous blob in the high dimensional space. That’s the area of well solutions that we’re trying to engineer for around between and so on. It includes certainly the physics scenario that you defined up front at that origin that multifysics spec and some slight variations around it or on that space manifold if you will.

6:13 But this space is much broader than the one-off CE solution that took you weeks to kind of assemble and fidget with and maybe send for review and get feedback that you didn’t really understand, but you tried other things. And that’s still constraining the surrogate predictions that are like trying to like pick different spots around this space and still have no way how to like navigate between those spots on this space.

6:44 A program or a simulator outputs many simulations. So subtle difference there in nomenclature simulator versus simulation. The simulations that are output by a program like a differentiable physics program represents continuous sets of the solution space. Analogously it provides this purple vector space up here or the set of all possible vectors that can be created using those original multifysics specs. The view at Pastor is that if you build differentiable physics programs or rather a software platform of applications that run differentiable physics programs, you empower engineers to really survey or navigate the full space of well what physics allows and rather than like that fundamentally limited and I would argue biased space that your initial CAE setup that initial vector was well pointing to and definitely what any sort like narrow surrogate or massive foundation model trained on your specific CAD data set is limited by.

8:02 So by making physics programmable with our simulation intelligence stack and the digital interfa sorry digital engineering interfaces that make it actually usable by CAE data scientists computational engineers mechy’s aerospace engineers and so on that’s what we mean by pass labs is building the IDE for reality and I would say I’m a little biased but I would say that this IDE for reality is Well, provably the best place to build and integrate physics AI.

8:40 There’s a saying that we have around the company. Don’t simplify solutions of scale. Automate complexity to accelerate. In other words, autonomy speeds time to market and enables iteration which increases reliability and fuels innovation. There are many ways foundation models really don’t do this nor do bespoke surrogate models. Foundation models they simplify. They scale for the sake of scaling. And the foundation model approaches in digital engineering they try to simplify that physics space by assuming a few a bunch of things but namely that we already know all the physics like we can just put those in a data set and shove it into this box and throw tens of millions at some clusters and then something interesting happens.

9:32 And it’ll just work if the kitchen sink is big enough is kind of the the logic there. One-off simulations or these custom surrogates, bespoke models, they really double down on complexity. Teams of scientific machine learning experts are needed to basically start from like the way upstream end of your your pipeline data prep-processing formatting and setting up machine learning experiments working with different surrogate architectures to find in training algorithms to find things that are trading off objectives that you really don’t care about.

10:10 They’re all machine learning objectives about like learning rates and convergence and lat representations and then maybe getting to like a memory footprint at the end. But it’s okay. We all have like I don’t know a couple hundred H1 H 8100 GPUs to spare, don’t we? On the left here is kind of the the latent space that we want out of models that represent physics solvers or incorporate physics solvers or that we work with in digital engineering workflows.

10:40 We want things that are yeah it’s going to be high dimensional but simple continuous you can navigate. You have interpolations between points or samples along that space that are grounded in physics and you have those guarantees. Foundation models with this illustration at the right are closer to something that is discontinuous, unreliable, you cannot navigate along that surface. So when you see a foundation model trying to iterate through different geometries, it’s pulling off like little independent points at different like peaks and troughs in this highly complex highdimensional space.

11:17 And if it tries to interpolate or average between those spaces, it is far more likely than not that is actually off that manifold and is something that is not consistent with the physics foundation models. We’ve heard about a few of them in talks today. Again, I have my biases. I’m supposed to as a founder and CEO. I think mechanical and aerero engineers are looking at something more useful and pragmatic their models in automotive in a lot of similar sectors.

11:55 We’re seeing foundation models demonstrated. All right. Bespoke surrogates now. And ML accelerated simulations basically beefy clusters that will take your ANSA setup and then throw it somewhere in the cloud and you get a big bill a couple weeks later. They are not doing away with the complexity like I suggested is a approach. They’re really doubling down on the complexity to make sure that you need them. This is a really well-known figure from about a decade ago in machine learning systems and machine learning engineers all know this paper kind of not verbatim but well enough that it’s very clear.

12:37 The stuff in the middle is fun. It’s cool. It’s interesting. It’s exciting. It’s a lot of like I don’t know what our startups here are focused on. It is like a tiny cog in this big noisy machine. And it doesn’t work. And also like it won’t tell you it doesn’t work unless you’re really good at all the other things. That’s what I mean by wrangling complexity. I I just kind of like started listing a bunch of the things that you don’t get when you see like a surrogate that is solving a problem.

13:15 U I think you get the point with this list. All right. So, back to this I don’t know perspective credo that we use at Pastor quite a bit. I’ve said a lot about like what doesn’t fit that mold. So, automating complexity to accelerate. These are some of the ways that we’ve built the SI platform to automate that complexity out of the way so engineers can accelerate in their roles and actually like supersede their roles is what we’re aiming for.

13:54 Our approach is not including not one AI model that’s going to do all of geometry or all of some sort of physics. We have flexible multi-ysics modules. These are programmatic. You can think of each one of these as a program or a function. And these are all modules that are end to end differentiable. Because our platform is end differentiable. And they are can flexibly combine. They can swap in and swap out for your problem at hand or when your problem definitely changes.

14:28 Maybe you have a different objective like at the start for accelerating the first batch of simulations. But then you want to have some like iterative work with an engineer like the workflows that we have in automotive sectors where we have things like what if surrogates. So you have a a mechanical design engineer or a safety engineer that is trying to query with a simulation or based on downstream information that they get from a team or a supplier or someone they don’t know and ask why questions like what if I do this why does that happen?

15:10 This is a complicated one. And the intention of this map is to kind of like boil down the complexity but basically this is a playing field a view of what we call our surrogate zoo. We have work in all of these architectures especially the simple ones down here that are really useful and really fast and lightweight. And what we do is we have are building up benchmarks and measures that are human understandable along these axes here.

15:43 So the complexity and the dimensionality so the representation space the dimensions at the inputs and the outputs and scaling laws. So when autophysics te’s up or recommends the right surrogate model or set of surrogate models rather multifysics modules for your problem you know where that’s coming from and it is trading off those scaling laws and based on those benchmarks because we’ve built and run the experiments and validated way before you even start using the SI platform.

16:16 Again, check out my talk at this podium last year. We really are not ignoring the the giant data engineering, but really data interfaces problem of well digital engineering and really if there’s any AIdriven digital engineering. I think my quote last year was something like if you think you don’t have this data problem, you just haven’t run into it yet. And we ran into it very early like four years ago and we’re building this engine environments product for our internal IML staff.

16:48 The little nuggets that we’re getting out of the company were just showing how industry really really needed this sort of data engineering pipeline. We’re still building, testing, validating, and extending the number of CX tools that can be flexibly combined. So, expect this one to come out early next year. This one’s already out. This is open source. This is our Kubernetes for physics AI. I mean, it says it all right there.

17:26 Trying to distill I mean CE tools heterogeneous hardware and optimization downstream constraints or objectives or inputs oh and then maybe your memory bottleneck is different on this machine versus a different machine that your team is using and that’s why we built this product and also why we open sourced it. It’s called Tessirect. Check it out. Right. So, at the end of the talk, I’m getting to the title of the talk.

17:59 I hope some people are familiar with this unreasonable effectiveness perspective by Eugene Vner back in the 60s. It’s really about this uncanny like pre-addaptation between abstract formalism and empirical truth. I hope this is starting to make a little bit sense. The abstract formalisms on the left, empirical truths on the right. And really going from left to right, what is the implication here? It’s that building systems for differentiable physics programming enable the kinds of AI machine learning that computational engineers actually need in practice.

18:39 Otherwise, you risk kind of getting lost in the CML complexity or the incomprehensible AI scale. There are more talks on unreasonable effectiveness that are closer to the deep learning and machine learning community that talk about like the emergent effects the synergies that happen based on things that we don’t quite yet understand. This is a figure also from the start of this company like why we are preer platform approach.

19:10 We’re building that simulation intelligence operating system. You can see a few things like multifysics and differentiable programming and talked about when you put those together you really get this 1 + 1 equals 3 effect that’s what we are at pester labs again bias the best in and we’re building products on top of that differentiable physics programming layer so you can benefit from these in in computational engineering barely have time so I’m glad I saved like this demo thing at the end when I made fun of demos at the beginning.

19:46 Right here is one of these autophysics workspaces. And this is for an HVAC subsystem that’s part of a larger data center system. This is another workspace I think with the same user. But this is like a dev branch off of like the source of truth. Everything here version controlled like why not behave like computer programmers collaborating on GitHub. Feels like they should have been brought to mess decades ago.

Even better, these are all sub comp or components and subsystems of a larger system. Gosh, it is messy to try to pass information between different CAD models and assemblies and especially when it’s forward backward gradient-based information. But these connections that you see in in our autophysics workspace, that’s what that means. That’s all continuous gradient based information passing between these blocks. You are propagating the language of machine learning through your assembly.

20:51 So the unreasonable effectiveness of simulation intelligence I kind of want to throw that back at you with this question. Why have an engineer build one simulation or model for one task when you can have that engineer run a simulator with simulation intelligence on a thousand tasks? Thank you. To see the full recording of this and previous presentations, as well as information about future CDFM events, visit CDFAM.com.