NVIDIA Corporation (NVDA) Earnings Call Transcript & Summary

Hello, everyone. Thank you for joining in for today's session. Deep dive into NVIDIA's physics ML solution with Modulus. I'm your host Bhoomi Gadhia, Senior Product Marketing Manager for AIM simulation, and I'm joined here today by my colleagues, Ram Cherukuri and Pavel Dimitrov. Ram is a Senior Product Manager for AI and simulation and works closely with Modulus engineering team and end users to bring new technologies and key capabilities in the areas of physics-based machine learning. And Pavel Dimitrov is a senior solutions architect who works with customers and building solutions primarily in the energy space but he has a wealth of experience in overall Modulus and physics ML. Before we begin, I would like to cover a few housekeeping details. At the bottom of your screen, you can find various bridges for you to use in the event. If you have any questions during the webinar itself, you can type them in the Q&A panel, and we will try to answer them at the end of the event. A copy of today's slide deck and additional materials are available in the resources list. We encourage you to download any resources or bookmark any links that you may find useful. And with this, I will hand it off to Ram and he will get started.

All right. Let's get started. Here's the high-level agenda for the talk today. We would like to share with you what we mean by physics ML and discuss why we believe it's a game changer for the engineering and scientific community. Then we'll see how Modulus as a framework can enable you to get started and build physics ML models by walking you through a couple of demos. And finally, I'd like to leave you with suggestions and tips on how to get started yourself in exploring physics ML methods for your own application. These are the 3 key takeaways I'd like to focus on this session. First, I'd like to highlight how physics ML can be a game changer and Modulus is the best framework for building physics ML models. And hopefully, point you to resources to help you get started. Before we begin, it is important to highlight some of the reasons why we are so bullish about these physics ML methodologies. And here are my 3 key reasons. First, physics ML models are fast because AI influence on modern GPUs is very, very fast, even for large systems of the order of seconds. So you can predict or infer high fidelity simulation output in mere second. Second, the models learn from data, either simulation data or observation or experimental data. This can reduce the burden on the engineers on configuring tools like the meshing tools or [indiscernible] settings or unknown physics in terms of unresolved processes. The models learn from data, which means the community can work together on creating good data sets to help create these models. Third, the methodology is highly scalable. And here, I'm also using scalability more generally to also address the generalizability of these approaches. As you may see in the news, AI models are growing larger and larger in terms of trainable parameters. But here, we also mean scalable in terms of how these models can scale from small to large applications with little work. In fact, efforts are ongoing to make these models more and more generalizable. So what is physics ML? Simply put, it's the term we used to categorize machine learning methodologies that build models, that to the first principles of the governing principles of a real-world physical system. The very loose definition. But here, I have called out 2 key reasons to make such a distinction. Firstly, AI at a basic level is about learning patterns from data. But finding any correlation from given data is not sufficient, not for engineering or scientific applications. Physics ML is about learning correlations that are caused by but are the result of the governing first principles. The second aspect is that deep learning model from other AI mature disciplines like computer vision and natural language processing don't just plug and play for physics ML. Let me touch on a couple of key reasons. The availability of data and by extension, the data sets is limited because data is typically more expensive to generate compared to computer vision data sets. Also, most often, these data sets are proprietary. So you cannot expect or depend on the data alone. Plus, these models also tend to suffer from convergence issues, bias issues and generalizability issues. So we need better models that can address these challenges. Before we get into what types of physics ML approaches are possible, let's see what one can do with physics ML models in the context of a simulation workflow. Here is the simplified illustration highlighting the general steps in the simulation workflow. You have CAD tools for creating geometry and to take the geometry to create a simulation mesh, use solver codes or ISV solver packages to stimulate the system by post-processing tools for analysis. This is typically iterative at various levels, but let's focus on the outher most loop of design iterations for them. Physics ML models can augment such a workflow by using the simulation data to create high fidelity circuits. To train a physics ML model using the simulation data and use it to infer new design points to explore much larger design space because the cost of generating a new design point is of the order of a couple of seconds. Let me share a couple of examples. Here is one of our early case studies where we demonstrated in use of physics-informed neural networks for product design and development. Our physics ML model was trained in Modulus to solve the conjugate heat transfer problem for a parameterized heatsink with about 10 design parameters such as fin height and thickness within certain ranges. Train model was then used to explore about 59,000 design points to find the optimal heatsink design. Each iteration took only a few seconds on a V100 GPU. You can run 59,000 design iterations in parallel on multiple GPUs. You can refer to this example in the corresponding recipe in Modulus documentation through the link here. In a similar vein, we had an early adoption partner Kinetic Vision, who built a physics ML model for the design of a 3D air-knife system for their customer. They trained a physics ML model using Modulus to simulate the flow of a laminar jet and they ran design iterations to identify the optimal design point for the trailing edge of the nozzle. They also described their approach in the blog here. Now another way of utilizing the ability to infer in near real time is for Digital Twin applications. Here, I have one of our recent case studies where the NVIDIA research team demonstrated how to develop a physics ML surrogate for the reservoir for carbon sequestration application. Here, the data from the simulation was used to train a neural operator that can solve for the Darcy flow. And as is the case with most of our case studies, we have provided a recipe for this in the modulus documentation. Finally, I also want to highlight the work that NVIDIA Research is doing in the climate and weather domain to highlight the potential of physics ML approaches in tackling really challenging scientific problems. To make your forecast net is a physics ML model trained on 10 terabytes of Earth system data. It is the engine behind efforts to create a digital twin of the earth. This physics ML model emulates global weather and lets us predict the behavior and risks of extreme weather events, such as hurricanes and atmospheric reverse with greater confidence, and up to 55,000x faster compared to traditional weather prediction models. Please refer to the links on the slide for more details on this amazing work. And there are several other such case studies for developing surrogates to serve as industrial digital twins using Modulus, and I have a link here to the research support to learn more about them. Now this is just one aspect of how physics ML can augment current simulation workflows. Another area of great potential is in leveraging physics ML methods to accelerate the solvers themselves. There are ongoing efforts in this direction within the community, such as to use a physics ML model for solver initialization and/or to incorporate physics ML models for certain components of a solver like for turbulence modeling or wall modeling. This is an area where we expect to see a lot more in the near future. And now that we have seen a glimpse of the potential of physics ML, let's turn to a quick overview of Modulus. NVIDIA Modulus is an open source framework for building, training and fine-tuning physics ML models. It is built for domain experts and with AI developers in mind, those that think in terms of symbolic partial differential equations as well as those that think in terms of configuring model training uses. Special emphasis has been put to make it easy to use. Framework itself is Python-based and the core is open source and well documented to make it easy for exploring new research ideas as well as translating research into development and deployment. Modulus is released under the Apache 2.0 license to support an open ecosystem that can promote collaboration and explore the full potential of physics ML. Now there are several approaches for integrating domain knowledge into machine learning and different research teams. These approaches range from methods that strictly enforce physical consistency in the ML models to methods that allow a relaxed usage of scientific knowledge where our scientific understanding is weak. Here is a very broad categorization of supervised learning approaches. The spectrum covers physics-driven recipes where you have the physics or the partial differential equations to guide the lost functions. You also have physics-guided architectures that use only data to train and the spectrum in between where hybrid approaches that combine the partial differential equations in terms of loss functions with data-driven approaches. But also a combination of using these models with solvers for hybrid simulations. There is a need for such a variety of approaches given the diversity of use cases and applications in the engineering and scientific disciplines. So the goal at Modulus is to support these different approaches and to enable the scientific and engineering community as well as the AI research community to explore and accelerate the development as well as the application of this physics ML methods. Within Modulus, we provide recipes as a starting point and also some key specific examples and samples for model architectures to make it easier for domain experts and new users. I will now hand it off to Pavel, who will pick a couple of these physics ML approaches to dive into ideas behind it and also to demonstrate the thought process when solving problems using these approaches.

Thank you, Ram. We only have time to quickly demonstrate one popular physics ML approach. But I'll start by briefly discussing the 3 main types of physics ML models that Modulus support. I'll touch on physics-informed neural networks or PINNs, neural operators and graph neural networks. And after the overview, I'll demonstrate how to build a PINN. Okay. Building physics-informed neural networks, PINNs for short, is an approach to training neural networks that use partial differential equations that express physical loss. We still use a-gradient based minimization approach, but instead of minimizing the mismatch between the predicted and desired value of the unknown function U at locations X, we minimized the misfit residuals obtained by subtracting the left-hand side from the right-hand side of the equation. This is the pure physics mode. The locations X are arbitrary and inside the desired domain, so we refer to this approach as mesh 3. If we know something about U in the form of XU pairs, then we can combine the pure physics approach and the pure data approach into a hybrid one that minimizes both types of losses. Another interesting feature of PINNs is that we can easily represent families of partial differential equations by introducing parameters. In this example, heat equation in one dimension is shown, and we have X that represents the one-dimensional segment between 0 and 1, but also parameter A that modifies the heat source. This is the scenario when PINN shine. We can have 10s or even 100 parameters that effectively store the solutions to the full family partial differential equations into a single PINN model. Training might take a while to converge, but inference is very fast. In a way, the PINN is like a random access memory for the family of PDEs that allows to retrieve the solution only at the desired locations, and that makes it a great fit for parameter exploration or Digital Twin applications. For example, in the Digital Twin application for a heat recovery secondary generation unit, we've modeled steam flow and droplet formation in a complex network of pipelines. We can parameterize the inlet velocity. And once the model is trained, only sample it at the desired locations to determine the likelihood of corrosion over time. The net effect is that the PINN model may be orders of magnitude faster than traditional methods. What is more, it's mesh free, and that makes it significantly easier to set up in the first place. PINNs are great, but they do have limitations. For example, if the number of desired parameters is large as in the case of planetary scale or weather modeling, then PINNs become very inefficient. Neural operators directly address that issue. Suppose that we have a grid over the whole earth and at each point on the grid a parameter value is provided. The problem that neural operator techniques address consists of taking that large set of parameters and learning how to map it to another set of values on the same grid, which are the result of a complex function that transforms parameters. For example, in seismology, the parameters might be the various velocities in the subsurface and the output is the pressure distribution of those same locations but obtained by [ obeying ] the wave equation. Again, this maps billions of parameters to billions of output values. Modulus supports 2 types of neural operators, the Fourier neural operator and DeepONet, who support data value-based type of training and are working on making it easy to add physics-informed versions in the same way that PINNs work. In fact, strictly speaking, neural operators do not always require a grid, but they're difficult to use when training geometry must differ substantially from the target inference geometries. Graph neural networks are a much better fit when training and inference may have drastically different shapes or geometries. The idea behind this approach is to learn local interactions so that the desired physical process is captured. Here, local is defined on the graph as, for example, n hops from a node. As the animations illustrate, a mesh is required, that is how graphs are formed here. But this mesh maybe totally different for the training data set and the target inference data set. The approach works well, maybe even better than PINNs and neural operators for transient or time-dependent problems. And like with neural operators, graph neural networks are available now in Modulus as a database training workflow, but we're working on extending those workflows to include physics-informed versions as well. To give you a sense of how Modulus works in practice, let's take a look at an example. Okay. So now we're inside of the Modulus tool chain environment, which is simply a Jupiter lab environment with a few additional tools installed already. I have prepared it so that we can run the very first example in the tutorial, the Chapter 1 tutorial on essentially creating a very simple but nontrivial physics-informed neural network. We started by creating a project with MTC create project. That is how we created this directory, and it was automatically populated with a number of files and sub-directories. Inside of the sub-directories, we have documentation. And when you double click on it. There's also a tutorial. And when you go into the tutorial and right click on index, open with the markdown preview, then we see the tutorial and that is I would go to the Chapter 1, Hello World and Tutorial. From there, we took this code and we copied it into the problem.gui file, which is where we define the mathematical formulation of the problem that we want to solve. So now that we're inside of the project, we can do MTC show problem, and it will summarize the problem for us. It will tell us that we want a single network to be used with import specs and outputs U. U is the unknown function, function of X. And there are no sub-models defined, but there are some constraints, the fusion constraint and the boundary constraint. The fusion is simply the second order heat equation effectively. And there's a boundary condition that essentially says that there are the 2 ends of the interval 0,1, we want the function U to take the value. So that's what MTC trial problem does. Other thing that's useful about MTC trial problem is that we ever -- if we ever make a mistake here and we type MTC show a problem, this will fail, and we know that our definition is incorrect. This is the first debugging level type of tool that we have. Okay. So what does this code do? These important statements are standards and you just have to import them just to be able to define the problem. Line 4 is where we start the actual work, neural network simply declares that we need a neural network to do something. And it also declares symbols for us that we will be using later, the symbol U, which is the unknown function that we'll be using later. And the symbol X, which is the variable so that we have a function U of X that we will be trying to compute somehow. Now after this, we need to define where that function is defined, and typically, we do this by using a geometry object, in this case, a single line segment a 1D between 0 and 1. And we will be defining constraints on sub-domains, and we define the sub-domains with one of the 2 types of sub-domains, interior and boundary. And we always need to give them a name. It doesn't have to be interior boundary. We can just give it some name so long as it's different and sufficient. And the sub-domain is defined on a geometry. So for example, in this case, the geometry is just a one segment. The interiors so domain will be everything in the interior of interval 0, 1, the boundary is going to be just the point 0 and 1. That's how the 2 sub-domains differ. And then the last thing we have to do here is to actually define the equations and the constraints that we want to enforce. So the diffusion equation, really the heat equation here is defined like this using the sin(pi syntax, U is a function of X, and it's actually a sin(pi) symbol as well and the sin(pi) expression, which is why we can do .dif X,2 to express taking the derivative of U with respect to X. And then EQ is an equality operator, again from sin(pi) so really, what this means is that we have the second derivative of U with respect to X plus 1 is equal to 0 and that is also shown here. And then finally, we formally defined a constraint. Again, we have to give it a name. This name is used when we just play it here and later in the process. And then we have to tell which equation we're going to be using and on what domain. Okay. So now what we can do is to actually train the model. The model is defined. So what we can do is to say MTC in Netcom, we need to initialize the configuration. And that's the command that does it. And then we do MTC train and the training will start. At this point, another directory is created called Training. Inside of that Training we'll have a number of stages. This is for multistage training. And so in a simple case, we'll only have a single stage. And inside of it, we'll have a number of things created. You can see MTC Train actually started by compiling the training script for stage 1. And we did this by taking this definition and actually creating Modulus training script, which has been run and the model was created and trained. The other thing that it did was to also create an infer.py file a module that actually allows us to reuse the model. This could be after training or during training after each time the model is safe to... And so what we can do now is to create a notebook, and start using the model. We do this by importing the inference module, and we also import NumPy and [ math.lib ] just so we can play the results. Here we can also -- the data, it's a single 1D example. And then infer 1 is the module that we imported. Infer is the function that was automatically created and compiled for this particular problem. And so we can run it in this fashion to then compute. And there you have it. We just created a PINN, we trained it. We defined it, we trained it, and we use it now. Now we can use the inference as many times as we want. Okay. So we built the first PINN and we ran it. It's pretty simple. And to make it useful, we'll have to modify the formulation. So how can we do this? Well, the Modulus tool chain allows us to gradually build our models by iterating on the mathematical formulation. Let's continue with our example. Let's say, we want to modify the source term in our heat equation. For example, you might want to make it as a function of position, like so. Next step, is to retrain the model and see what it looks like again. In order to do this, we first run MTC clean, remove the previously trained model, MTC show problem, it's always a good idea to run just to make sure that we haven't made any mistakes. Now we've updated the constraints. Now we can run again MTC train to retrain the model. All right. So the model has been retrained. Now we can switch back to our inference notebook and run it again. But this time, we have to reload the kernel and run it again so that we load the newly trained model. There you have it. Just modified the model, retrained it and saw the result. With Modulus, we aim to drastically reduce the barrier to begin developing physics ML models. We do this by providing many preset defaults and automatic tools that eliminate the low-level tinkering normally required when using deep learning frameworks. Variety of deep learning architectures, model training policies that require little tuning, debugging tools and so on. As the previous demonstrations illustrate, our tools allow domain experts, scientists and engineers with little or no background in machine learning or deep learning to get started and be productive quickly. Domain expertise is always needed to build physics ML models. And for some problems, that is all Modulus requires. However the default configurations will not always work even if the mathematical problem is well understood in the context of traditional numerical analysis. Physics ML is still a new scientific area with an active research community. New ideas and approaches are frequently published and we recognize the need to add these new developments to Modulus. For this reason, the Modulus framework provides multiple extension points. We invite the community to contribute innovations at all levels, from neural network architectures to training workflows to integration with external tools and beyond. Now, if you're a scientist or an engineer or perhaps a machine learning expert who has just developed a new method, you might ask why Modulus? Why should I contribute? Perhaps the best answer is that Modulus can help you scale. You can keep working on the core of your innovation and Modulus will simplify both your development time and provide a wide variety of deployment options. Modulus SDK allows to develop and train physics ML models either on a desktop with 1, 2 or up to 8 GPUs, in a data center environment with multiple nodes where the number of GPUs is virtually unlimited. And then for deployment, tools like the Triton inference server can span the full spectrum of computing devices. We can deploy in a large data center or all the way down to the smallest edge device. If, on the other hand, your professional is still wondering why and how physics ML might fit in your industry, here are 3 reasons. First, physics ML models may be fast. Orders of magnitude faster than traditional methods in applications like digital twins or parameter exploration during product development. Second, they might be the only way to combine field data and physics constraints in a single model, despite simplified time to solution or provide a convenient primary inversion mechanism. And third, physics ML models are scalable. This is because our Modulus has decay, simplifies training, whether it's on a single GPU or thousands of GPUs. And because on the deployment side, we provide software infrastructure to scale deployment as well.

Thank you, Pavel and Ram, for your wonderful presentation. So you can get started with Modulus going to the product page. You can also look at the documentation and then also take the self-paced learning course on the DLI website. You can also try Modulus on the cloud with NVIDIA LaunchPad. And last but not least, we can download Modulus from the NGC container and the GitHub page. All these resources are available to you in the resource list in the webinar itself. So please go ahead and click at those links and bookmark them as well as the presentation for today's webinar is also available in the PDF format for you to go ahead and download it.

Please take your questions in the Q&A panel, and we will go ahead and answer them now. All right. We have a lot of questions that have come in during the presentation. So the first question is how do you use Modulus in Omniverse platform? And what is the workflow? Does it work with other applications in Omniverse?

Yes. Good question, Bhoomi. So we have Modulus connector to Omniverse. As you know, Omniverse is the platform for Digital Twins, from NVIDIA. And the whole idea we had Omniverse you can develop connectors. So similarly, we have a Modulus connector that you can use to essentially bring in the train model and use it for visualization in interactive inference, right? So the workflow will still be that, you train the model in Modulus. And then we provide a template, which lets you to bring in that train model into Omniverse so you can use it for -- not just for visualization, but in fact, you have a parametrized model, you can change things and rather inference in near real time and get the new simulation visualized. Regarding the question about connecting to other applications, yes, the whole idea we had on Omniverse you can be able to use different connectors and you can actually build your own applications on top. So we have not done any specific work to do that. We actually -- the Omniverse ecosystem. That's what we expect will have people who already have applications and are developing new applications to use these different components to build their own application. There are a couple of links that might be helpful to kind of look at the workflow. If you search for Omniverse Modulus, you'll be pointed to the documentation. Maybe we can also post it in the chat later on. So that kind of gives you sort of more details about the workflow, and we also had a blog. So those would be good pointers to understand what the workflow looks like in more detail.

Okay. Thank you, Ram. We also have a blog you can go to like Modulus resources and then find that blog as well. So that blog has like instructions and how to do it, like we have a tutorial video and things like that, too. So that's a very good resource, and we'll try to put -- give the link here in the chat as well. Okay. Then next question is, is it possible to solve a variational calculus/neural problems with Modulus?

All right. Yes. Good question, actually. So this is a good example to reinforce what we sort of conveyed during the presentation. The way I would think about this is, can machine learning or deep learning techniques be applied to [indiscernible] systems. And the answer is yes. I think there are -- there's quite a bit of innovative work and research that's happening in this space. Then once you, let's say, take one such use cases in mind, the question then comes is, can Modulus help implement those techniques and approaches. And again, because it's a wide -- it's a broad topic that we're talking about in machine learning, what I can say is once you identify a use case where you see a deep learning network being trained for such systems, you should be able to implement that in Modulus. And the reason for that is, right now, Modulus is very flexible and kind of it's also open source for that reason is you can actually -- it's not restricted, right? Maybe if -- in the process, you find some limitations, that's something that the team can help you with, but being open sourced and customizable. You should be able to implement those models for a specific use case. So that's the way I would think about this particular question.

Yes. Got it. Okay. The next question is, does Modulus still support TensorFlow 1.x as a back end? If not, why? I believe an earlier version used to.

Yes. Again, good question. So we think about a year ago, decided to move to PyTorch mainly because our goal with Modulus is to help accelerate the work on the physics ML space. And a lot of the research work at the point was coming out with PyTorch as the framework of choice. So in order to facilitate ease of translating that research work into application development, we made the choice to support PyTorch as our primary back end. So Yes, TensorFlow 1.x is not a back end anymore. It's mainly PyTorch. If you guys are looking at -- we have customers who have asked for JAKs, and they are seriously looking at it. So we are looking at the trade-off. But yes, if there's strong reasons to support TensorFlow 2.x, we'll be happy to listen to it. But right now, PyTorch is the main back end.

Got it. Okay. The next question is how the graph neural network is implemented in Modulus?

Right. So maybe that's -- the better way to answer that question is to actually look at the source code, right? So we -- if you search for Modulus launch, and we'll post this link in the chat as well. You can actually look at the implementation of graph networks. The release of Modulus that is coming up, which is in about a couple of days. This is the general access. We already have a beta version of that out in the open. So you can actually look at the code. You will be able to see how graft neural networks are implemented. In fact, we provide a couple of recipes as well to show how GNNs can be used for certain example problems. So we have a vortex shedding example that uses a MeshGraphNet. And we also have GraphCast, which is one of the state-of-the-art weather prediction models. So those are good examples to look at to get a feel for how you can start leveraging GNNs in general, but also in Modulus.

Right, right. Yes. And then we'll have the blog on and stuff we got to, so you could refer to that, too, for more information in a couple of days. The next question is, is there a way to embed Modulus into the process flow of computational codes in languages other than Python like Fortran, C, et cetera?

Yes, that's an interesting question. So maybe I'll split that into 2 portions. So if you're thinking about models, physics ML models that are trained in Modulus, and then incorporating them into the process flow. I think there, we have -- we will rely on other development -- sorry, deployment stacks that we have, right? So you can train the model in Modulus, and you can use something like Triton to include these models into computational codes, right? I think Triton does have other front ends that you could use and that could -- and Triton is designed for deployment. So I'm sure that there is a path available there, we can look into the specifics. But the other way to look at this question is to almost embed training into the process flow. And if that's the line of question, currently Modulus only has a Python front end. It does not have other interfaces like Fortran or C or C++. So yes, that's where we are today. Again, we'd love to follow up and understand more details of what you guys are thinking of doing.

Yes, exactly. Okay. The next question is, what's the minimum GPU needed to learn this? And the following to that is, is there a cloud instance that will allow this naturally without too much installation efforts.

Yes, great question. So Modulus can be run. In fact, I should say that you can start running training of physics ML models using Modulus even on a RTX 3090 laptop GPU -- laptop grade GPU. So that's kind of minimum requirement, but it is also dependent on the problem that you have at hand because what tends to happen is as -- depending on the size of your problem, you might run into limitations with memory or RAM, right? So those kinds of issues can happen. So it is problem dependent, but for just getting started, even trying simple problems, you can do that on an RTX 3090. In general, our recommended platform is something along the lines of A6000 workstation. So that is a good -- that is sort of a hardware platform that gives you a healthy balance between GPU memory as well as the compute capabilities that you need. But that's also if you're looking for advanced applications and use cases. Now when you're thinking about cloud instances, NVIDIA just announced availability of NVIDIA and DGX Cloud. So that would be very relevant because our focus with these cloud instances is to make sure -- to kind of make sure that it's very easy to set up different stacks, including Modulus and you can run it. We test it as part of our QA process. So that will be my recommendation if you're looking for something that's quick to get started. In fact, one of the links that we provide about Modulus availability on LaunchPad is essentially a trial experience for the same. So that's why we included that as a resource. But for whatever reason, if you want other options, we have customers who run Modulus on AWS because we have container images, so you can easily install on AWS instances and get going. Again, this was a lot, but we have provided some information in the Resources section to get started. And as always, if you guys need to know -- you want to learn more or need our help, please reach out to us.

Right, exactly. Also, we have Rescale support, right, Ram?

Yes. Good point, Bhoomi. So we also do work with partners such as Rescale. Rescale is a platform company. Essentially, they make it easy for end users to use software in the cloud. So it's a -- we work with them to essentially in the same regard as Modulus is installed on their platform and you can actually use their cloud infrastructure to just run Modulus without worrying about any of the installation process. So yes, that's another aspect you were looking for.

Right, exactly. Great. And then the next question is to ask the demo offline of MTC material. So we can give them guidance like how they can reach out to us, maybe forums or NVIDIA Modulus e-mail?

Yes. So -- again, the simplest answer here is MTC, the Modulus tool chain, there is a dedicated GitHub repo which is, again, open source, and it has tutorials. So a lot of this -- a lot of the presentation and the demos are a part of that repo already. So I'd say that's the first to start. But again, as Bhoomi mentioned, if you guys are interested and you need more help, yes, please reach out to us, and then we will probably think -- work through the specifics of how to get you started.

Right. Yes, there are development forms so you can go to like a forums.nvidia.com, that's the link. And then you can go there and search for Modulus and then you can ask the question there, and we'll be happy to answer there. And then once you type the question, then we get your e-mail address as well so we can reach out to you if you need further assistance and one-on-one guidance around things. There is a question that we already answered about LaunchPad access, but there is a follow-up to that, like what is NVIDIA LaunchPad and how does it work?

Yes. So like to put it simply, NVIDIA LaunchPad is a trial cloud setup where we let the users experience the product without the hassle of having to install, right? It's a managed service. So we have the cloud infrastructure. We get everything set up for you so that you can immediately jump into how to use the product and kind of get into that experience. So it does two things. One is, it gives you the experience of using the product on a trial basis, but also it addresses one of the previous questions, right? That is something that you guys prefer as a workflow, you can actually use DGX cloud instances as a follow-up to continue that journey. So that's left the dual purpose of NVIDIA LaunchPad. And the way it works is we have provided the link in the Resources section. Because it's a trial basis, it does -- the requests are vetted by our account teams and we use that process to essentially curate who gets access because it is a limited resource. And that's the current process of how the requests are addressed.

Okay. Awesome. The next question is the new open source Modulus. Is there a plan to release the PySDF library so that it can be installed locally?

This is a question we get often. So the PySDF library for the foreseeable future will still remain close source mainly because it is a library we depend on. It is actually developed and used by a couple of other products as well. So for that reason, that has remained as closed source. It's also not something that the Modulus team owns entirely. So that's the reason why we have not released the PySDF library. So it is currently delivered as a combined library that people can still use and install and run. But yes, open sourcing of that is not currently being discussed internally.

Got it. Okay. The next question is, what are the advantages of physics ML methods compared to traditional [indiscernible] or remodeling matters such as projection based methods?

Yes, great question. So again, maybe we can spend a lot of time on this question, but maybe I'll try to have a couple of key let's say, benefits of physics ML models in a way that they augment other reduced auto modeling techniques as well, right? So one of the primary ones is that with physics ML, the whole idea is you're able to generate high fidelity simulation outputs, right? It is the quality of the -- let's say, the accuracy of the train model is not just at par with your traditional numerical methods, but also, in some cases, it can surpass, right? We have had instances where either because of the fineness of the mesh or some of the assumptions that you take into consideration with the solver, that is absent with physics ML models because you could, in fact, be just learning purely from data or the PDs themselves, right? So that's one of the really important takeaways is the goal with physics ML methods is the output is high fidelity, and at the same level as your traditional numerical methods. So that's one benefit. The other benefit is also -- again, this is kind of a little problem dependent. But for auto modeling, you need to come up with potential design of experiments and there's kind of a workflow around it. That might be a little limit sort of unnecessarily in the case of physics ML methods because depending on the approach you choose -- and like maybe this is a [indiscernible] situation, but let's assume that you have a publicly available dataset that has been used to train a model, you can, in fact, use that off-the-shelf models with little training overhead to use. So maybe -- those are a couple of things that come to mind immediately. But the way to think about physics ML methods is they do augment what we do today, and in fact let's us do a lot more. So that's a way to think about that.

Awesome. The next question is, would it be possible to solve transient cylinder example presented using GNN with PINN in a pure physics approach?

Yes, great question. So -- in fact, the latest release I was referring to earlier, it will have a GNN example for transient cylinder. And so in fact, the vortex shedding that happens as part of it. So that's the example that we have, but it only uses a purely database -- sorry, data-driven approach with the GNN. We are going to be working on incorporating -- when you mean PINN here, it is to kind of inform the loss with PDEs. We are going to be doing that. So that's work to be done. In fact, we encourage the community to actually try it out and let us know what they succeed with. But yes, right now, it's a data-driven example that we're going to have, and we're going to augment that with the PINN as well in the near future.

Okay. The next question is, could you please provide the link to the precompiled PySDF library?

Yes. I think that should be available as part of the GitHub repos off the top of my head, but I can double check and confirm that. So we can follow up off [indiscernible].

Sure. Yes. I'll note that name, and then we'll follow up with you. There are a lot of questions coming in, so trying to make sure we're not like repeating the same one. Okay. The next one is, do you provide consulting services to accompany your customers? Are you engaged in joint research initiatives with universities or technology centers to solve real-world problems?

Yes. That's a loaded question. So yes, we do work -- thinking about that a little bit. So in terms of consulting services, we don't have dedicated services to package with the use of Modulus primarily because Modulus is an open framework. And part of the question -- part of the challenge in applying is, in general, understanding, hey, can physics ML be applied for a certain problem, right? So -- having said that, we do have solution architects within the company who selectively engage with the different customers. So if there is a need for that, please reach out to us. We can -- again, there's a different organization we engage with to kind of go through that qualification process. So that's about helping customers build solutions using Modulus and using physics ML. In terms of joint research initiatives, yes, I think in general, I think there's a -- NVIDIA as a company, we have collaborations for all the various products that we do. We have lots of joint initiatives with universities, and Modulus is no different. So we work with different universities. We support them through the compute resources and direct engagement with our engineering staff as well. So that is definitely available. And I really like the point about solving real-world problems because that is really the objective with Modulus. Physics ML is -- when I say it's going to be a game change, it can't be true unless we applied for real-world problems, right? So seeing some application of it for some canonical problems is great. But that's a starting point. A lot of our work has been in trying to stress test and push the limits of these approaches, by trying to solve these with real-world problems, engaging both at university as well as with customers. That's what we've been primarily doing. And most of our work, we try to publish via samples or recipes because we know that this is just a point along the journey, and there's more work to be done. So hopefully, that was a loaded question. Hopefully, this gives enough clarity.

Yes. That's very clear. The next question is, will you also publish pre-trained physics model operators?

Yes. No, great question. So -- in fact, we have that already with our previous releases, but in a very naive way, which means -- and then I'll explain why. So we -- all of our examples that we had where we demonstrate different physics ML architectures and models, we also published the pretrain model mainly to simplify the user experience, right? So if somebody wanted to quickly see the what the model can do, they can pick up the checkpoint and at least run inference. Now that's not scalable because how these -- for a couple of reasons. One is, we do want to increase the number of recipes we publish, but just having pretrained checkpoints for each that cannot be used for a different use case is kind of not very -- not a high ROI activity. So for that, what we are now trying to do is trying to curate some sort of a model mainly because while we do want to still enable ease of use, we are trying to, let's say, start on the path of figuring out what are some of these architectures that can have some generalizability, right? Because that's one of the core principles behind this question, I'd imagine, is if I have a pretrain model, can I use it easily for sort of a connected but slightly different application. And to be honest, that is currently a research question, how generalizable are these architectures. I kind of mentioned during the presentation as well. But we are taking steps to at least start curating these models and publishing them as part of a model so that it can help either answer some of these questions or provide impetus for more research in this space.

Right, right. Yes. The next question is, can you give me some insight on how to choose PINN, DeepONet, GNN or other architecture?

Yes. Kind of having full circle, maybe this is a good question to end at because the honest answer is that's the secret, right? Like I think that's where we think the domain experts, their understanding of the problem space is very critical. And also the research that's ongoing is very critical in figuring out because most problems and especially whenever we work with customers, the answer is you can apply multiple such approaches for any given problem. Of course, there are limitations with one versus the other in some cases. But it is really problem dependent. And we are actually -- this is an area of active research. We think -- at least we hope the community will invest a lot of time in kind of digging into such questions. And the holy grail here is can there be a set of architectures that are so generalizable that they can be used for certain class of applications, right? Like just to take a previous question that we had and it's a hypothetical statement, but if you can come up with architecture X, Y, Z that can help solve all CFD problems, that's the hope. Whether that's possible is something we have to wait and see. But that's a very long-winded way of saying that there's no one answer for this. It is very problem dependent.

Right. Exactly. Okay. Thank you so much. We do still have a lot of questions that are in the queue, but we will answer them individually. Hopefully, we can get their email addresses so we can answer them. But thank you so much, everybody, for attending. We encourage you to download Modulus to try out Modulus. And on NVIDIA LaunchPad, there is a full 4-hour self-paced learning course on NVIDIA's website. You can go ahead and try that as well. And all of these links are again in your Resources section of this webinar itself as well. And then on this today's presentation is also in the Resources. So thank you so much to Ram and Pavel for your time for the presentation. And thank you, everybody, for attending and giving us the pleasure of your time. Have a great day or evening, everybody.