[mcanoenen]

Hello dear colleuges,

I have encoded a CFD model for the flow between two parallel plates in the two dimensional space. But, when I solve the same conditions on the Ansys Fluent, it takes way shorter simulation time and number of iterations to get a convergent solution compared to my own code do. Also, in a convergent solution I am getting the same results between the analytical soluton, Ansys Fluent solution and my own CFD solution. But, somehow Fluent runs faster

Could you please explain me the reason why it's like that?

My code uses:
1) Finite Volume Method with Staggered Grid
2) QUICK, TVD, CD, UD and LUD Schemes (All of them slower than Fluent)
3) Under relaxations for velocities and pressure also included

Best regards,

mcanoenen

[LuckyTran]

These are all high-level schemes that determine the linear system needing to be solve. You need to consider what actually is the linear solver and how is it setup?

Here is an example of what it sounds like:

Analytical Problem

3x+1=2

Fluent code

3.01x+0.99=2.01

Your code

3.14x+1.01=2.11

Okay but what is the actual root finding algorithm that you use to determine x? Different schemes change the coefficients from 3 1 and 2 to other variations, but they don't formally alter the speed of the calculation until you run into overhead issues.

[arjun]

In year 2007 to 2008 when I wrote my very first Navier Stokes solver I stumbled upon the same problem. The code was stable on very simple hex meshes and anything with tetra the solver would it was unstable. Let alone the fact that Fluent was faster.

Off course no one can tell here why Fluent is faster than your code or anyone's code because most people do not know what Fluent does and the ones those who know are not allowed to talk about it.

Now that I have so many years of experience with this and my own code is quite stable, I would say that the stability comes from two reasons

1. Accuracy of descretization. It should be correctly done.

2. Limiting the variables and the change in variables.

In your case the change in variable is such that solver converges slower (its like 3 steps forward and 1 step back, while fluent will be 3 steps forward).

[sbaffini]

Originally Posted by mcanoenen

Hello dear colleuges,

I have encoded a CFD model for the flow between two parallel plates in the two dimensional space. But, when I solve the same conditions on the Ansys Fluent, it takes way shorter simulation time and number of iterations to get a convergent solution compared to my own code do. Also, in a convergent solution I am getting the same results between the analytical soluton, Ansys Fluent solution and my own CFD solution. But, somehow Fluent runs faster

Could you please explain me the reason why it's like that?

My code uses:
1) Finite Volume Method with Staggered Grid
2) QUICK, TVD, CD, UD and LUD Schemes (All of them slower than Fluent)
3) Under relaxations for velocities and pressure also included

Best regards,

mcanoenen

Also, don't underestimate the fact that you're talking about a piece of code which has been under optimization for more than 20 years.

Finally, have you been using all the relevant optimizations of your compiler? What the profiler says about your bottlenecks?

[mcanoenen]

Thanks for the everyone responding my question.

Actually, my code is fairly simple. I only used rectengular grids in my code. While using it I also adapted the staggered grid and under-relaxation factors for the velocities which are solved using Gauss-seidel Method. For the Pressure Equation I used Over-relaxed Gauss-Seidel Method which is regarding the SIMPLE method. Other than those, I haven't used another optimizations. Would you enlight me about it if there are any optimization left you think as an absence in my code?

Originally Posted by sbaffini

Also, don't underestimate the fact that you're talking about a piece of code which has been under optimization for more than 20 years.

Finally, have you been using all the relevant optimizations of your compiler? What the profiler says about your bottlenecks?

[sbaffini]

Originally Posted by mcanoenen

Thanks for the everyone responding my question.

Actually, my code is fairly simple. I only used rectengular grids in my code. While using it I also adapted the staggered grid and under-relaxation factors for the velocities which are solved using Gauss-seidel Method. For the Pressure Equation I used Over-relaxed Gauss-Seidel Method which is regarding the SIMPLE method. Other than those, I haven't used another optimizations. Would you enlight me about it if there are any optimization left you think as an absence in my code?

I was specifically referring to compiler optimizations like loop unrolling, vectorization, etc. Or more simply, what compiler are you using and what's the string you use to compile your code?

A basic aspect that I haven't even mentioned is caching, assuming that you have your stuff correctly accessed in memory.

But, now that you mention that, note that algorithmically, Gauss-Seidel typically looses against AMG (yet, there are exceptions, but it's too much detail for the case here).

In the end, there is so much to look at that, let's face it, unless you have spent a decent amount of time in optimizing your code, the expectation to be just faster than Fluent only because you are using a structured code is, don't take me wrong, kind of naive.

[mcanoenen]

I see there are topics I am unaware of. Thanks for the informations. I am going to optimize my code in my further studies.

regards,

mcanoenen

Originally Posted by sbaffini

I was specifically referring to compiler optimizations like loop unrolling, vectorization, etc. Or more simply, what compiler are you using and what's the string you use to compile your code?

A basic aspect that I haven't even mentioned is caching, assuming that you have your stuff correctly accessed in memory.

But, now that you mention that, note that algorithmically, Gauss-Seidel typically looses against AMG (yet, there are exceptions, but it's too much detail for the case here).

In the end, there is so much to look at that, let's face it, unless you have spent a decent amount of time in optimizing your code, the expectation to be just faster than Fluent only because you are using a structured code is, don't take me wrong, kind of naive.

[arjun]

Originally Posted by mcanoenen

Thanks for the everyone responding my question.

Actually, my code is fairly simple. I only used rectengular grids in my code. While using it I also adapted the staggered grid and under-relaxation factors for the velocities which are solved using Gauss-seidel Method. For the Pressure Equation I used Over-relaxed Gauss-Seidel Method which is regarding the SIMPLE method. Other than those, I haven't used another optimizations. Would you enlight me about it if there are any optimization left you think as an absence in my code?

Fluent uses AMG and that makes lots of difference. Even though you might converge the linear system to the same tolerance the AMG part of solver does make a lots of difference. (this i have noticed)

The reason is that errors over longer range are corrected by AMG that you need for pressure equation.

[mcanoenen]

Thank you, it is as far as I noticed a multi-grid technique. I was also of the idea that a solution methodology makes the difference more than of optimizaition issues in compliers -of course when we don't mention about head to head competetion-. Because I developed my solver using Matlab, I'm not allowed to optimise the complier as Matlab does that.

Those instabilities are getting stronger in my solver is seen in the picture below. that is because I use a non-newtonian fluid.

https://ibb.co/z7r3yh5

Originally Posted by arjun

Fluent uses AMG and that makes lots of difference. Even though you might converge the linear system to the same tolerance the AMG part of solver does make a lots of difference. (this i have noticed)

The reason is that errors over longer range are corrected by AMG that you need for pressure equation.

[sbaffini]

Originally Posted by mcanoenen

Thank you, it is as far as I noticed a multi-grid technique. I was also of the idea that a solution methodology makes the difference more than of optimizaition issues in compliers -of course when we don't mention about head to head competetion-. Because I developed my solver using Matlab, I'm not allowed to optimise the complier as Matlab does that.

Well, then I think I know the main reason your code is slower

EDIT: Just to be clear, you can't expect MATLAB to be competitive with anything compiled and reasonably coded, not to mention extremely optimized codes. Even if you use the exact same algorithms (which is not the case here) and a perfectly vectorized code, there would still be gaps here and there, stuff you don't even have control of in the first place when using MATLAB.

[Continuum]

Originally Posted by sbaffini

Well, then I think I know the main reason your code is slower

EDIT: Just to be clear, you can't expect MATLAB to be competitive with anything compiled and reasonably coded, not to mention extremely optimized codes. ....

Yes, totally agree. I ran a simple for loop grind test a few years back comparing Matlab compiled to an EXE with the GB embedded run time engine. It was about x500 slower than compiled C code for the same simple floating point operations. I had to do this to get the point across to the development group that just because it was a compiled EXE, it was not faster that running inside the Matlab environment.


For your consideration: https://www.mathworks.com/help/compi...b-runtime.html



There are still many things to learn here though. To the OP, I would suggest exploring different solution methods on different conductance matrices. You could still do this in Matlab and compare general differences. For example, you could program semi-direct methods such as conjugate gradient and compare these to a simple SOR based method. You need only create one pinch point to spread the Eigen values to slow SOR.



Regards

[arjun]

Originally Posted by sbaffini

Well, then I think I know the main reason your code is slower

EDIT: Just to be clear, you can't expect MATLAB to be competitive with anything compiled and reasonably coded, not to mention extremely optimized codes. Even if you use the exact same algorithms (which is not the case here) and a perfectly vectorized code, there would still be gaps here and there, stuff you don't even have control of in the first place when using MATLAB.

All this is when both the codes are reducing the error to same levels with each iterations and both converge in same number of iterations.

I am very sure this is not the case here, Fluent will converge smoother and would take less number of iterations.


PS: Its not that fluent can't be beaten, have done that multiple times (even had their pressure coupled solver beaten from segregated algo) but it is not going to happen from a simplistic code.

[mcanoenen]

Thanks for your answers,

May I ask another question?

In the solution of a newtonian case, I also encounter a wawing residual graph which is not seen in Fluent solutions.
Is it because I don't use a multigrid technique or it is definetely unnatural behaviour that I shouldn't encounter with such situation?

[sbaffini]

Every minute detail of a numerical discretization and solution method can make a difference.

With this clear in mind, residuals falling in this way may be connected to the use of certain linear solvers, including SOR (or, maybe, especially, because that's strictly related to higher values of omega). When you use it for linear problems this happens because you "move too much" in the wrong direction when reducing the residual. Gradient descent and conjugate gradient kind of already solve this (take a look at the image here to see what I mean https://en.wikipedia.org/wiki/Conjugate_gradient_method).

For non linear problems the residual you look at is not even linked to the linear system and there are a bunch of other reasons that could promote that behavior. However the linear system solver might still be one of them.

EDIT: you are probably learning, so this is ok, but MATLAB has plenty of options to solve linear systems, so one possibility to check would be to then promote your code to use the MATLAB infrastructure for low level parts as this