[hbulus]

Hello everyone,

For a long time, i am experiencing OF with cases which are unstructured tetrahedral meshes. Those cases are really meshed very well including boundary layers and refined local regions. Cases are for external flow analysis, mostly transonic regime. Even though i tried lots of settings, i cannot run cases correctly. Whatever i tried is not good enough for tetra meshes. It seems OF works well with only hexa meshs, for best snappyHexMesh should be adviced.

Prof. Jasak advices reconCentral for tetrahedral meshes but it did not help me at all. Likewise pointLinear shows some improvements, but it is not enough too.

Is there anyone who can claim that i can run external flow dynamic cases which are made of tetrahedral meshes ?? I am really curious about what you got achieved?

Sorry for tough attitude, but the results make me really pissed off.

Have good days!

Edit: I can share a constant and 0.orig file, if you let me know how to share 80 mb zip file.

[Tobi]

Hey, ... don´t be pissed of ... other software toolboxes for which you pay a lot of money are even more crazier - maybe not in that particular regard but in other topics.

Can you show us the fvSolution, fvSchemes and controlDict file?

[kishpishar]

Hi Tobi,

I second the above opinion about tetrahedral meshes but have no problems in accepting your assertion about other software toolboxes

Coming to the topic, I have also observed that hex meshes (from snappy or other software) perform far better in terms of convergence behavior with turbulent flows. I haven't gone to the extent of modifying reconCentral scheme for OpenFOAM standard version but tried a few other things with the numerical schemes. The best performance so far was obtained with the combination:


Would you please give me some suggestions? Thanks very much,

-Kumar

[Tobi]

Hey, ...

the schemes do look okay. However, the gradient scheme could be modified by using the cell or edge limiter. Gradients should be calculated corrected in order to get correct results. Furthermore, nCorrectors could help stabilizing the solution within one SIMPLE iteration (not sure right now which solver you are using but for simpleFoam we don´t have that option).

And I second you. Hex-Meshes are great for numerical simulation but are not applicable always. By the way, Fluent uses the polygon meshes mostly and the coupled solver. However, the solution will blow up while using other algorithms such as SIMPLE or SIMPLEC.

[hbulus]

Thanks for quick responses.

Sorry but i dont agree about your opinion about Fluent. I mostly use Fluent as pressure-based segregated solver for steady-state external problems. Even though I only use tetra meshs, and most of them are not the best meshes, it can really handle very well. If you can detail your experience about fluent, i will be very grateful.

I attached my bcs and schemes. I prepared this settings for 0.84 Mach, 3.03 aoa Onera m6 case. I tried rhoSimpleFoam and rhoPimpleFoam. What i sent is for rhoSimpleFoam case.

Thanks for your collaboration.

Extra Note: What i sent can handle at some point very well, but after some iteration it just blows up. I refined mesh , problem should be numeric. If you want, i can send the residual plot.

[hbulus]

I forgot to add mesh check result. Here it is. As you can see it fails but it is due to inflation layers.

[Tobi]

Common practise is to set the laplacian and snGrad to the same scheme (check out kishpishars files). I am not a big fan of the linearUpwind as it also introduces some unphysical behavior.

So my first approach would be:

• Use upwind and bounded schemes first
• Use higher order schemes if the upwind is fine

A comparison of numerical schemes in OpenFOAM, mesh density, cell types and OpenFOAM versions is given here: https://holzmann-cfd.com/community/n...sport-analysis


All cases I had in Fluent in HVAC analysis crashes almost after a few iterations using SIMPLE or SIMPLEC algorithm. Even a almost converged solution by using the coupled scheme crashes immediately. However, I will not work with fluent too much anymore, hence, I don´t care

[hbulus]

Thank you, i noted everything you said.

Your Convective Schemes Analysis is very helpful, also thanks for that.

I am just curious about that have you ever made successful analysis which are fully made up tetrahedral meshes ?

[Tobi]

Honestly, since I am using FOAM, I never used tetrahedral meshes. However, there is a talk on YouTube from Hrv. Jasak. He is talking about tetrahedron meshes and numerics. So in principal I would say, we can work with tet meshes.

[olesen]

Originally Posted by Tobi

Honestly, since I am using FOAM, I never used tetrahedral meshes. However, there is a talk on YouTube from Hrv. Jasak. He is talking about tetrahedron meshes and numerics. So in principal I would say, we can work with tet meshes.

Even in the old days with STARCD and/or STARCCM+ always stayed far away from tet meshes. If you have a tet mesh, can try using its poly dual - should be better. However, the polyDualMesh in OpenFOAM will look a bit dodgy at concave geometry features. To be really useful it would also need some cell splitting there (easy to conceptualize in 2D, not so easy to implement in 3D).

[Tobi]

Originally Posted by olesen

Even in the old days with STARCD and/or STARCCM+ always stayed far away from tet meshes. If you have a tet mesh, can try using its poly dual - should be better. However, the polyDualMesh in OpenFOAM will look a bit dodgy at concave geometry features. To be really useful it would also need some cell splitting there (easy to conceptualize in 2D, not so easy to implement in 3D).

Obvious, I forgot the polyDualMesh application. Nevertheless, I never worked with tet-meshes and hence, no experience. Is it still tricky to work with tets and FOAM?

[hbulus]

Originally Posted by Tobi

Obvious, I forgot the polyDualMesh application. Nevertheless, I never worked with tet-meshes and hence, no experience. Is it still tricky to work with tets and FOAM?

polyDualMesh does not come with beauties, was useless for my cases. In my opinion, tet meshs seems to be the weakest point of OF.

[kishpishar]

Hi Tobi,

Originally Posted by Tobi

the schemes do look okay. However, the gradient scheme could be modified by using the cell or edge limiter. Gradients should be calculated corrected in order to get correct results. Furthermore, nCorrectors could help stabilizing the solution within one SIMPLE iteration (not sure right now which solver you are using but for simpleFoam we don´t have that option).

As much as I remember, I did a few tests with all the 3 least square schemes - the standard one, edgeCell and the pointCell versions and observed really no substantial improvement with any of these. I've only attempted steady cases with simpleFoam with relatively simpler geometries, but have some observations.

In my experience, it is not that tetrahedral meshes are useless with OF, rather it is often the case that convergence is quite bumpy and the residuals don't fall to the same levels as with Hex meshes. It may still be possible to obtain reasonable looking solutions.

Here are a few suggestions from my limited experience:

Mesh:

As far as possible, generate tet meshes with nearly equilateral triangles with smooth size variation. This would make the average non-orthogonality higher compared to Hex meshes, but the maximum non-ortho will be around 60. The solutions might still oscillate but the solver crashes etc. can be avoided.

Turbulent model:

kEpsilon seems to work better with this type of meshes than the other variants realizable, RNG etc.

fvSchemes:

• Gradient: use leastSquares with or without a cell Limiter. If using cell limiter, use it only for U, k and epsilon (not for p)
• divSchemes: bounded Gauss upwind (use always first order schemes)
• snGrad: limited corrected 0.333 (or in worst case, uncorrected)
• laplacian: Gauss linear limited corrected 0.333 (or in worst case, Gauss linear uncorrected)

fvSolution:

• relaxationFactors: use 0.5 for U, k, epsilon

If the above combination doesn't work, there could be mesh problems in the regions close to boundary layers. Better remesh without boundary layers and see if the problem persists.

[hbulus]

Originally Posted by kishpishar

Hi Tobi,



As much as I remember, I did a few tests with all the 3 least square schemes - the standard one, edgeCell and the pointCell versions and observed really no substantial improvement with any of these. I've only attempted steady cases with simpleFoam with relatively simpler geometries, but have some observations.

In my experience, it is not that tetrahedral meshes are useless with OF, rather it is often the case that convergence is quite bumpy and the residuals don't fall to the same levels as with Hex meshes. It may still be possible to obtain reasonable looking solutions.

Here are a few suggestions from my limited experience:

Mesh:

As far as possible, generate tet meshes with nearly equilateral triangles with smooth size variation. This would make the average non-orthogonality higher compared to Hex meshes, but the maximum non-ortho will be around 60. The solutions might still oscillate but the solver crashes etc. can be avoided.

Turbulent model:

kEpsilon seems to work better with this type of meshes than the other variants realizable, RNG etc.

fvSchemes:

• Gradient: use leastSquares with or without a cell Limiter. If using cell limiter, use it only for U, k and epsilon (not for p)
• divSchemes: bounded Gauss upwind (use always first order schemes)
• snGrad: limited corrected 0.333 (or in worst case, uncorrected)
• laplacian: Gauss linear limited corrected 0.333 (or in worst case, Gauss linear uncorrected)

fvSolution:

• relaxationFactors: use 0.5 for U, k, epsilon

If the above combination doesn't work, there could be mesh problems in the regions close to boundary layers. Better remesh without boundary layers and see if the problem persists.

Thanks for information. Do you have any experiment with tetrahedral meshes with this settings? I mean can you verify what you are saying ?
If you can enlighten us, i'll be very grateful.

[kishpishar]

Originally Posted by hbulus

Thanks for information. Do you have any experiment with tetrahedral meshes with this settings? I mean can you verify what you are saying ?
If you can enlighten us, i'll be very grateful.

All that is written above comes from my experience on fully tet meshes.

[hbulus]

Originally Posted by kishpishar

All that is written above comes from my experience on fully tet meshes.

What i am asking is that whether did your analysis with tet meshes converge as should be or not ?

[Tobi]

Originally Posted by kishpishar

Hi Tobi,

Turbulent model:

kEpsilon seems to work better with this type of meshes than the other variants realizable, RNG etc.

fvSchemes:

• Gradient: use leastSquares with or without a cell Limiter. If using cell limiter, use it only for U, k and epsilon (not for p)
• divSchemes: bounded Gauss upwind (use always first order schemes)
• snGrad: limited corrected 0.333 (or in worst case, uncorrected)
• laplacian: Gauss linear limited corrected 0.333 (or in worst case, Gauss linear uncorrected)

Based on your output it seems that the more diffusion you add, the better the results get (as it is a common point in fluid dynamics).

• kEpsilon should have more diffusion compared to others such as RNG
• divergence scheme upwind will introduce a lot diffusion error which smooths out the gradients and support stability

The only thing that I am not happy about is that for bad things you set an uncorrection term to the laplacian and snGrad scheme? Hence, you don't take into account for non-orthogonal correction. I am not sure if you introduce (again) diffusion here? But commonly, the error introduced for non-orthogonality should be taken into account.

[kishpishar]

I summarized my observations only in the context of steady state incompressible flows using simpleFoam solver.

Originally Posted by Tobi

Based on your output it seems that the more diffusion you add, the better the results get (as it is a common point in fluid dynamics).

I would put it this way: the more diffusion you add, the stabler your results will be.

Originally Posted by Tobi

• kEpsilon should have more diffusion compared to others such as RNG
• divergence scheme upwind will introduce a lot diffusion error which smooths out the gradients and support stability

Agree.

Originally Posted by Tobi

The only thing that I am not happy about is that for bad things you set an uncorrection term to the laplacian and snGrad scheme? Hence, you don't take into account for non-orthogonal correction. I am not sure if you introduce (again) diffusion here? But commonly, the error introduced for non-orthogonality should be taken into account.

Agree with you. I was only suggesting the uncorrected scheme as a last resort, in the interest of convergence - if everything else fails with bad meshes. I think this introduces further diffusion as the non-othro error is not corrected. By the same logic, some amount of diffusion is there for limited corrected schemes too, depending on the coefficient of limiter. This error reduces for the limiter coefficient in the order 0 ---> 0.2 ---> 0.33 ---> 0.5 ---> 1, where 0 means uncorrected and 1 means fully corrected.

In a practical sense, aren't such finite volume CFD calculations a trade-off between stability and accuracy? You try to use the combination of schemes that give you the best possible accuracy for the problem at hand while maintaining stable runs..

[hbulus]

Originally Posted by Tobi

[/LIST]Based on your output it seems that the more diffusion you add, the better the results get (as it is a common point in fluid dynamics).

• kEpsilon should have more diffusion compared to others such as RNG
• divergence scheme upwind will introduce a lot diffusion error which smooths out the gradients and support stability

The only thing that I am not happy about is that for bad things you set an uncorrection term to the laplacian and snGrad scheme? Hence, you don't take into account for non-orthogonal correction. I am not sure if you introduce (again) diffusion here? But commonly, the error introduced for non-orthogonality should be taken into account.

Dear Tobi, i would be very happy if you can work a case which is made up fully tetrahedral meshes(+3D, Compressible, transonic/supersonic regime, turbulent flow), then share your result. I ask from you because you become one of the idols in OF ecosystem. I know you are working HVAC in special, but i will insist on external aerodynamics. This kind of comprehensive work does not exist. As you can be aware, we only talk in theory or untidy experiences. Not a single tutorial or material exists. Does this fact make you to think something

Thanks for your kind responses, have good day.

[Tobi]

Hey,

well there are a lot of things to do so I don't think that I am able to create a test case .

... one of the idols in OF ecosystem...

Thanks for that compliment but I don't think I am an idol. There are so many good foamers around (sometimes they are not working voluntarily and for public sources as I do). However, there are crazy people around who understand the things much better compared to me.