[sharonyue]

Hello guys,

It looks PINN is quite popular and it is used to solve PDE. There are tons of papers that employing PINNs to solve NS or similar equations. However, I am wondering if PINN will defeat FVM regarding on the CFD application in the short run or in the long run. Any opinion is welcomed.

Thanks.

[LuckyTran]

Neural networks are just the latest and greatest tools in inference, which is a fundamentally different category than algorithmic arithmetic. NN's are basically solving for an approximate mapping from A=>NN(A)=>B. and then finds an approx'mate B' from A'=>NN(A')=>B'

Arithmetic, calculates B from a mapping from A, i.e. B=f(A) and then B'=f(A').

NN's are an advanced form of curve fitting. When Gauss invented least squares or when his predecessors invented curve fitting, none of them claimed that curve fitting would replace make linear solvers obsolete. And we use linear solvers nowadays wayyy more than they were used in Gauss's days, by orders of orders of magnitude. NN's offer an alternative field of growth for applied computing and is especially suitable in fields where accuracy is not a concern, but it is not predator in the computing ecosystem and both will likely continue to evolve together just as linear solvers and statistical toolboxes have grown together in the past

Finally, NN's still need to be re-trained whenever the inputs or the mapping changes and so you will need tools to do to provide this training.


We still teach kids how to find exact solutions to 1+1=2. We are unlikely to ever accept an ANN response like 1+1 is approximately 2.01

[sbaffini]

Let me first say that the fact itself that PINN (can) exist is fascinating and amazing.

Now, I know very little of PINN but, computational physics, as a whole, is about numerically solving the mathematical version of a physical problem with known and controllable error bounds. You take that out of the picture and there's no more engineering in whatever remains. It is my understanding that this is, at least, a grey area, if not completely out of question, even for NN in general.

Second, there is an industry that actually provides computational tools for other industries to use them. Now, the mathematical software industry is a beast of its own and such that the remaining general software industry and coding at the academic and research level are both child games in comparison. It has standards, procedures, and infinite verification possibilities which simply can't be neglected. And this industry has found this thing, the unstructured FV method, which is order of magnitudes easier to implement, extend and maintain with respect to any other method out there, is as flexible and robust as you might dream, sufficiently accurate already at second order and trivial to work with in parallel on commodity hardware. I will also add that you need to be a non engineer to not understand how the FV is intrinsically based on a concept which is at the core of all our problem schematizations. We all understand conservation and the trivial fact that the more conservation statements (cells) you use, which are per se exact statements, the more accuracy you get. How powerful.

So, for sure, anything can happen, but that's the playfield, and PINN is not even playing the same game.

In fact, no serious person could ever claim that one is a replacement for the other. Kind of the same way LES is not a replacement for RANS, full 3D methods are not a replacement for panel methods or genetic algorithms are not a replacement for other optimization techniques.

[CFDfan]

The CFD theory, and especially its implementation, are in a sorry state and AI is maybe the thing needed to guarantee some degree of reliance on the results. Most of the industries would have been perfectly happy with 5-10%, but consistent, CFD accuracy.

[arjun]

Originally Posted by CFDfan

The CFD theory, and especially its implementation, are in a sorry state and AI is maybe the thing needed to guarantee some degree of reliance on the results. Most of the industries would have been perfectly happy with 5-10%, but consistent, CFD accuracy.

It looks like you need better cfd solver or you might need to learn how to use it.

5 to 10 percent of accuracy in results doesn't cut it and people get excellent results all the time.

[CFDfan]

Originally Posted by arjun

It looks like you need better cfd solver or you might need to learn how to use it.

5 to 10 percent of accuracy in results doesn't cut it and people get excellent results all the time.

Well, that's probably when you have some step or a cylinder, or a sphere, or some other basic shape for which you have the experimental results in advance and could play with the turbulence models, mesh density, etc. variables till you get some correspondence with the experiment. If you however deal with a complex 3D shape from the real world you'll be very, very lucky if you get 10% accuracy from the first run. And I mean from the first run, using the best practices and recommendations of a particular CFD code, because that's what is needed in 21 century. If you have to built a prototype and measure it and then start fiddling CFD parameters to get some closeness to reality you will be too late.
Just google "Ahmed body" which is an almost 50 years old paper with drag and lift coefficient measurements in a wind tunnel on an ugly, basic shape car. People have since then been writing hundreds of papers and PHD dissertations on this basic shape trying to get correspondence between simulation and experimental results. Over the years I've been keeping an eye on such papers and have never seen one that claims 1% accuracy for BOTH drag and lift coefficients. The majority of the authors (professionals like you) got satisfied with 5% accuracy of Cd and Cl.
And again, this is a silly 3D-shape with no, say, heat transfer. If the latter has to be studied in complex, electronic products with forced air cooling the accuracy of the major CFD cores is laughable. If AI is the only hope to fix this then let it be.

[arjun]

1. 5% of accuracy and within 5% of error margin are two different things. You should be little bit more clear on things. 5% of accuracy is very easy to get by while 5% within error margin well depends on what you are solving.


2.

Originally Posted by CFDfan

Just google "Ahmed body" which is an almost 50 years old paper with drag and lift coefficient measurements in a wind tunnel on an ugly, basic shape car.

While ahmed body is simple in shape, the physics involved is not simple. It has transitional turbulent flow where results heavily depend on separation etc.
You are confusing simple shape with simple problem. It is not an example of simple problem. Specially when turbulence is mainly unsolved problem.


3. Not all CFD is about calculating drag and lift for separating flows. People get good results for complicated geometry all the time. One complicated example does not decide the whole CFD field.


4. The accuracy of CFD solutions can be increased by using finer meshes and going towards LES/DNS. For example far difficult problem of rotating golf balls we got very accurate and reliable results using meshes of 2 billion to 4 billion cells.



Last

5. Solution of CFD solver's inaccuracy is more accurate methods (higher order, spectral methods etc) and finer meshes and NOT neural networks that are approximations in nature. Neural networks are specially bad idea for calculating drag and lift of a body (because then you are looking for more than pretty picture of an approximate flow field).

[sbaffini]

Originally Posted by CFDfan

Well, that's probably when you have some step or a cylinder, or a sphere, or some other basic shape for which you have the experimental results in advance and could play with the turbulence models, mesh density, etc. variables till you get some correspondence with the experiment. If you however deal with a complex 3D shape from the real world you'll be very, very lucky if you get 10% accuracy from the first run. And I mean from the first run, using the best practices and recommendations of a particular CFD code, because that's what is needed in 21 century. If you have to built a prototype and measure it and then start fiddling CFD parameters to get some closeness to reality you will be too late.
Just google "Ahmed body" which is an almost 50 years old paper with drag and lift coefficient measurements in a wind tunnel on an ugly, basic shape car. People have since then been writing hundreds of papers and PHD dissertations on this basic shape trying to get correspondence between simulation and experimental results. Over the years I've been keeping an eye on such papers and have never seen one that claims 1% accuracy for BOTH drag and lift coefficients. The majority of the authors (professionals like you) got satisfied with 5% accuracy of Cd and Cl.
And again, this is a silly 3D-shape with no, say, heat transfer. If the latter has to be studied in complex, electronic products with forced air cooling the accuracy of the major CFD cores is laughable. If AI is the only hope to fix this then let it be.

I don't see how the two things relate. It's like saying: "The bus driver doesn't feel well today, but there is this kid here that is super fast on karts, let him drive". Not gonna happen.

As a different example, in Italy we are, almost everywhere, at risk for earthquakes and most of the buildings, in certain zones, demand a sismic design, which is based on FEM computations. My question is: would you live in any such building knowing the computations came from a PINN? Especially for old buildings in hystorical centers, linked to other unaccessible buildings, maybe with several unaccessible underground cavities, the job is plagued by several uncertainties and is no less troublesome than turbulence and such. My genuine answer here is NO.

Besides the fact that adding new physics to a PINN requires retraining (so there is, in my opinion, the whole topic of IF and WHEN the economics of this tools really adds up), and you still need CFD to train or retrain, I feel very uncomfortable with the typical underlying message I can read: "you are either doing cfd wrong or uselessly, make it fast at least with AI". Maybe leave CFD for good if your desing doesn't really depend so much on results that it can afford the risk of random ones

[CFDfan]

Originally Posted by arjun

1. 5% of accuracy and within 5% of error margin are two different things. You should be little bit more clear on things. 5% of accuracy is very easy to get by while 5% within error margin well depends on what you are solving.


2.



While ahmed body is simple in shape, the physics involved is not simple. It has transitional turbulent flow where results heavily depend on separation etc.
You are confusing simple shape with simple problem. It is not an example of simple problem. Specially when turbulence is mainly unsolved problem.


3. Not all CFD is about calculating drag and lift for separating flows. People get good results for complicated geometry all the time. One complicated example does not decide the whole CFD field.


4. The accuracy of CFD solutions can be increased by using finer meshes and going towards LES/DNS. For example far difficult problem of rotating golf balls we got very accurate and reliable results using meshes of 2 billion to 4 billion cells.



Last

5. Solution of CFD solver's inaccuracy is more accurate methods (higher order, spectral methods etc) and finer meshes and NOT neural networks that are approximations in nature. Neural networks are specially bad idea for calculating drag and lift of a body (because then you are looking for more than pretty picture of an approximate flow field).

Arjun your comment on complexity/physics of the Ahmed body is just silly. Look at the 3D shapes in the world around you, or open a fan cooled power supply with hundreds of components with various shapes to realize that if a smooth like baby's ass Ahmed body is a complex CFD problem requiring 4 billion cells to accurately solve, then the real world CFD cases involving not only turbulent/ separating flows but heat transfer by convection/radiation, material porosity, fans with their PQ curves, thermal interface materials, etc, should be many many times more difficult to accurately solve. The Electronic industry is perfectly happy with 5-10% accuracy under the conditions I listed above, but from the first attempt and using say a high end computer. " Just give me something quickly even with a lower, but consistent accuracy so I could built a prototype that would work even not perfectly. I will refine it, during the next design iteration". That's what the industry cries for shortening the development time. If a cluster of supercomputers, running various turbulent models for many days is needed to process those billions of cells then this it is practically useless exercise. One can make tens of physical prototypes and optimize the design for less time and money.
Yes, you have your valid reasons, the processes are very complex, the CFD theory is underdeveloped, its implementation in the CFD codes is not satisfactory and that's what the users are currently facing when using the CFD codes - messy to setup, costly to solve and even worse - producing results with inconsistent accuracy. AI and NN seemed to me like a gulp of fresh air for getting out of the current misery. If AI, NN, PINN, etc. methods are not a panacea, then we are to stay in the mud for a very long time.

[arjun]

Originally Posted by CFDfan

Arjun your comment on complexity/physics of the Ahmed body is just silly. Look at the 3D shapes in the world around you, or open a fan cooled power supply with hundreds of components with various shapes to realize that if a smooth like baby's ass Ahmed body is a complex CFD problem requiring 4 billion cells to accurately solve,.

Never claimed that you need 4 billion points to solve Ahmeds body, that was claim about golf balls that are far more challenging that this Ahmeds body.

Still the point stays that body may be simple but physics involved is not. Your inability to understand this fact won't change facts.

What is silly is to think that approximate methods like PINN or networks trained on CFD results is going to bring you more accuracy.


There is no denying that with more resources CFD can produce far better results than approximate solutions.


Do you have any paper or references that show that PINN has produced better results than very fine LES (lets leave DNS aside)?

[LuckyTran]

I have a very sophisticated PINN that sits between my shoulders. But I never claimed that I would never need to do CFD or that anyone can do CFD without a brain. But evidenced by the fact that I still do CFD, it must be very poorly trained

Originally Posted by CFDfan

AI and NN seemed to me like a gulp of fresh air for getting out of the current misery. If AI, NN, PINN, etc. methods are not a panacea, then we are to stay in the mud for a very long time.

The seaweed is always greener in somebody else's lake–and so are their wallets

[arjun]

The way I see all this is that these could provide some quick estimations that are either usable or not based on user's demands.

But when someone (not you) is claiming that it would improve the accuracy that current state of CFD lacks then this is a claim that is very hard to believe.

For example if CFD is not so accurate then the networks trained on them will be equally (or worsely) accurate and not more. Then it leaves us with PINN only. Which begs the question what is the information these NNs are informed with that CFD can't be informed of. For example lets say NN is informed of Poisson operator then it can help make quick prediction of a Poisson equation. But could it be more accurate than what we could achieve with CFD (specially when very fine meshes are involved with higher orders). I very much doubt that PINN would out do CFD here in accuracy. So this claim is hard to be trusted until its proven otherwise.

This is what i think.

Originally Posted by LuckyTran

I have a very sophisticated PINN that sits between my shoulders. But I never claimed that I would never need to do CFD or that anyone can do CFD without a brain. But evidenced by the fact that I still do CFD, it must be very poorly trained


The seaweed is always greener in somebody else's lake–and so are their wallets

[CFDfan]

Originally Posted by arjun

Poisson equation. But could it be more accurate than what we could achieve with CFD (specially when very fine meshes are involved with higher orders). I very much doubt that PINN would out do CFD here in accuracy.
This is what i think.

Yes arjun, you are right. PINN will most probably be never more accurate than CFD. It is like "curve fitting" as somebody already pointed here, but if it produces quick and reliable result with up to say 10% accuracy that would make thousands of engineers very happy.
Look at the result chatGPT produces on a topic you are interested in. For sure it could be refined, but it is usable and quite close to your target. Some time ago I read that for its answer chatGPT processes information from 20 million sources and that number is probably higher now.
There is a huge difference of course between generating a text and generating a CFD result, but AI enhances with such high rate that in 5-10 years CFD could be very different.

[numrecipe]

The conversation about PINNs and their potential impact on CFD is fascinating.

Could PINNs act as a complementary tool for FVMs, particularly in scenarios where:
- Fast, approximate solutions are sufficient for initial design exploration or scoping.
- Perhaps PINNs could be used for a quick initial solution, followed by a more refined FVM simulation for critical applications.

As engineers,
- Have any of you explored using PINNs alongside FVMs in your workflow?
- What are some potential challenges of integrating these two approaches?
- Are there specific CFD applications where PINNs could be particularly advantageous?

[CFDfan]

Originally Posted by numrecipe

The conversation about PINNs and their potential impact on CFD is fascinating.

Could PINNs act as a complementary tool for FVMs, particularly in scenarios where:
- Fast, approximate solutions are sufficient for initial design exploration or scoping.
- Perhaps PINNs could be used for a quick initial solution, followed by a more refined FVM simulation for critical applications.

As engineers,
- Have any of you explored using PINNs alongside FVMs in your workflow?
- What are some potential challenges of integrating these two approaches?
- Are there specific CFD applications where PINNs could be particularly advantageous?

Yes it definitely could be, that would be the workflow.
On the second question - the electronic cooling would benefit a lot, and generally any applications where the accuracy of the input data is within the the desired accuracy of the results.

[numrecipe]

Why isn't there PINN solver for CFD out there? I've seen a few academic example but no production level code (OpenFoam, Fluent, StartCCM+, etc.).
Anyone aware of any development in the commercial space?

On a separate note, PINNs larger value might be in doing inverse problems.

[sbaffini]

Originally Posted by numrecipe

Why isn't there PINN solver for CFD out there?

Because an actual code that works is not a joke and the field also lacks several of the things that allowed "CFD software" to become an industry.

I would love to make a list about it and explain how the required rigor for a successful product is way beyond what anyone outside of it, including academia, even remotely imagine... but I would digress.

[sharonyue]

Originally Posted by numrecipe

Why isn't there PINN solver for CFD out there? I've seen a few academic example but no production level code (OpenFoam, Fluent, StartCCM+, etc.).
Anyone aware of any development in the commercial space?

On a separate note, PINNs larger value might be in doing inverse problems.

These days I tried using PINN to solve some basic flows based on OpenFOAM+libtorch. I did obtained some good results. But I did also find some issues:

1. PINN needs supervised points. I used PINN to solve lotka-volterra-equations (more info can be seen here: https://rf.mokslasplius.lt/lotka-volterra-equations/). Once the gradient gets a little bit larger, the loss does not go down. You have to add supervised points (collocation points). I dont think PINN without collocation points would work for practical flows in the short term, expecially for industrial flows. You may see some research articles saying that there traing does not collocation points, or very few points. At least it means it is a issue for PINN.

2. For any types of PDE, once the boundary condition changes, or anything changes, PINN needs to be trained again. Its not like CFD, if you modify boundary condition, you just run it again. The model of PINN needs to be trained again. Then it can be used. Others say you can use deepODE to handle this problem. But I haven't gone there yet.

3. PINN is very slow. For Riemann problem with 50 grids, OpenFOAM-FVM needs probably 1 second. PINN needs much much more than that (probably 100 seconds). I dont have the specific data right now. But the training is definitely very slow.

4. Combining OpenFOAM+libtorch is not trival. For example, I tried to use PINN to solve cavity steady state flow. Its a 2D problem. In libtorch, you can declare a 2d tensor to save your data. But in OpenFOAM, mesh label is sequenced by 1D array. Put it in another way, OpenFOAM address field by U[0], U[1],..., U[n]. Libtorch access data by U[0][0], U[0][1], or even U[0][0][0], U[0][0][1]. Combining OpenFOAM and libtorch needs to deal with the very basic date conversion. Meanwhile, libtorch is pretty a low level code. Whenever you need to do anything, for example, you need to implement another equation, you have to write everything FROM SCRATCH. In certain cases, you can take C++ as a low level language, OpenFOAM is a high-level language for CFD simulations. Its the same for Libtorch, which is a low-level language for CFD-AI. I also think in the future, maybe there will be some kind of TorchFOAM, or TorchCFD or whatever, which can make it more flexible. Before that, everything you want to do, you need to do very low-level coding, especially for libtorch part.

5. For industrial flows, I do think FVM is still competent since it has been developed for more than several decades. Everything in FVM seems to be very mathmatic. In PINN, it looks like its just fitting by computer. It does not require too much math. PINN does some very good job for certain flows. But it seems it does not have the beauty of FVM, in the point of math.


Some of my PINN codes based on OpenFOAM+libtorch can be seen here: https://cfd-china.com/topic/6967 in Chinese though. In this link, you may see the results (plots or contour plots) predicted by PINN+TVD, PINN for cavity flow, PINN for lotka-volterra-equations, or even easy linear regression problem. I also use OpenFOAM+libtorch to recognize if there is a shock in 1D flows. I even has some video to show PINN results. I am still playing with it, but I dont have much time to write a date interface connecting libtorch and openfoam. Right now everything from my side is hard-coded. Besides PINN, there are also lots of date driven model can be implemented in OpenFOAM+libtorch. I am also trying to do something new.

The last thing I forgot to add: PINN looks easier than FVM. In FVM: you have NS equations, you must handle the coupling problems. So we have SIMPLE, PISO, etc. In PINN, you have equations, you calculate all the derivitaves, you get the loss, you are almost done. You dont need to handle the coupling, the boundedness, the conversation. Ofcourse your results maybe unboundedness. Then you have to add another loss. Overall, it looks easier than FVM.

[numrecipe]

sharonyue,

Thank you for the detailed input. I think it summarizes the current state well.

I realize there a huge feature gap between what we require and SOTA of PINN.

Nvidia Modulus appears to be an higher-level abstraction for PINN and they have CFD example. I believe they use OpenFOAM data for training. Beside CFD integration into torch, what's preventing people from building on Modulus?

Have anyone considered using PINNs for specific scenarios where CFD struggles, like highly dynamic flows or multi-physics?

[FMDenaro]

And what about any theoretical foundation for which PINN could produce more accurate results than FVM ??