[naveen]

hi maruthamuthu_venkatraman

my self NAVEEN from INDIA...i hav completed my naca 0012 airfoil analysis case in openfoa 1.4.1 and 1.5....i got good results in both the versions...thanks for your suggestions....now i am doing MTech project on multielement airfoil analysis with double slotted flaps and i hav completed my grid in gambit(c-grid) and now i need to solve in openfoam...i am getting some errors like this during solving in openfoam 1.4.1

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/openfoam14/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/openfoam14/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib64/libc.so.6"
#3 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/openfoam14/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/openfoam14/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 main in "/home/openfoam14/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/simpleFoam"
#6 __libc_start_main in "/lib64/libc.so.6"
#7 Foam::regIOobject::readIfModified() in "/home/openfoam14/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/simpleFoam"

can u give me some suggestions whare i am going wrong and also suggest how to set boundary conditions.....

[vkrastev]

Originally Posted by maddalena

[...]
Number of cells of each type: [...]
tetrahedra: 445207 [...]
Checking geometry...
Overall domain bounding box (-1.865 -4.09798 -4.09726) (6.335 9.22699e-09 4.09726)
Mesh (non-empty) directions (1 1 1)
Mesh (non-empty, non-wedge) dimensions 3
Boundary openness (1.52724e-19 7.40957e-19 2.03325e-19) OK.
Max cell openness = 1.63569e-16 OK.
Max aspect ratio = 9.33635 OK.
Minumum face area = 5.21732e-07. Maximum face area = 0.156288. Face area magnitudes OK.
Min volume = 3.97085e-10. Max volume = 0.0188268. Total volume = 144.059. Cell volumes OK.
Mesh non-orthogonality Max: 65.4365 average: 20.2284
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.899635 OK.

Hi Maddalena,
I was just having a look around for useful/interesting discussions about external aerodynamics on unstructured grids, and I found this old but quite interesting tread...So, my question is: how did you obtain a so low max-skewness value on a 3D tetrahedral mesh? I think that my case is pretty different (bluff-body instead of streamlined-body, much larger mesh, etc.) but, however, using ANSA and/or Tgrid till now I was not able to reach max-skewness values lower than 1.8/2 ...
Thank you in advance

Best Regards

V.

[alberto]

My doubt is: did you try to use

leastSquares

or

cellMDLimited leastSquares 1

for gradients?

[maddalena]

Hi V,

Originally Posted by vkrastev

how did you obtain a so low max-skewness value on a 3D tetrahedral mesh?

well, I guess it is a sort of learning how to proper grading cells on basic connectors. As I learnt from Alberto, a good distribution on the 1D and 2D mesh will lead to a nice 3D mesh...
As an example... The mesh you commented on was generated in Gambit, at the moment I am using Pointwise and I get a max skew of 0.75-0.8...

Hi Alberto,

Originally Posted by alberto

My doubt is: did you try to use
leastSquares
or
cellMDLimited leastSquares 1
for gradients?

is this answer for me or is it a suggestion for V? What are the main advantages of least square in comparison of Gauss linear? Are they better suited for grid with high skew? Thank you, as usual!

maddalena

[vkrastev]

Thanks Maddalena...What you're saying is a big truth (I mean the need for a big amount of patience in building good quality meshes). Anyway, I've never heard about this Pointwise mesher: is it for free? Is it (in your opinion) better or simpler to use compared to the most famous commercial alternatives (Gambit, ANSA, Tgrid)? Thank you once Again


Alberto, if this is a suggestion for me, thank you too, but the leastSquares option (whether limited or not) does not seem to give any benefits in my case (I don't know if it's something about the OF version: you and another guy of the forum started a little discussion about it in the tread concerning the second order schemes, but I didn't understand if the leastSquares option is well implemented in all the newest OF versions, namely from the 1.6 till now, or not). Till today the best combination I've found for the fvSchemes is:


// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
default steadyState;
}

gradSchemes
{
default Gauss linear;
grad(p) Gauss linear;
grad(U) cellMDLimited Gauss linear 1;
}

divSchemes
{
default none;
div(phi,U) Gauss linearUpwindV cellMDLimited Gauss linear 1;
div(phi,k) Gauss upwind;
div(phi,epsilon) Gauss upwind;
div(R) Gauss linear;
div((nuEff*dev(grad(U).T()))) Gauss linear;
}

laplacianSchemes
{
default Gauss linear limited 0.5;
// laplacian(nuEff,U) Gauss linear corrected;
// laplacian((1|A(U)),p) Gauss linear corrected;
// laplacian(DkEff,k) Gauss linear corrected;
// laplacian(DepsilonEff,epsilon) Gauss linear corrected;
}

interpolationSchemes
{
default linear;
interpolate(U) linear;
}

snGradSchemes
{
default limited 0.5;
}

fluxRequired
{
default no;
p ;
}


// ************************************************** *********************** //

Curiously, this leads to good convegrence (and, indeed, to quite nice flow features description) only for the 35° slant case of the Ahmed body...The 25° slant case reaches only partial convergence (the residuals first fall down, than grow up and start to oscillate around quite high values, from 10^-03 to 10^-02), but interestingly the results in terms of flow visualization and aerodynamic force coefficients seem to be not so far fom the experimental ones (and also from other RANS steady-state studies I've found in the literature). Finally, the above mentioned settings lead (for both slant configurations) to a significant underprediction of the pressure-drag coefficient in the nose region of the body (about 0.0045 vs. 0.02 from the experiments), whether the drag contribution from the other body-components (lateral skin friction, slant and base pressure drag contribution) are much more coherent both with the experimental data and with previous numerical studies.

Best Regards

Vesselin (V sounds too much lke "V for Vendetta" )

[maddalena]

Hi,

Originally Posted by vkrastev

I've never heard about this Pointwise mesher: is it for free? Is it (in your opinion) better or simpler to use compared to the most famous commercial alternatives (Gambit, ANSA, Tgrid)?

No, Pointwise is not for free. I have chosen it for three main reasons:
1. It is the software I knew better when I started to look for a new mesher;
2. It has a direct Pointwise -> OpenFOAM export
3. It has a good way to handle with cyclic patches, that is an important feature for me.
That's it. However, I have not too much experience with other commercial grid mesher: only a couple of meshes with Gambit and with GridPro. And some (bad) experience with salome.

Originally Posted by vkrastev

Vesselin (V sounds too much lke "V for Vendetta" )

Thus are you not him???

Cheers

mad

[vkrastev]

Originally Posted by maddalena

Hi,

No, Pointwise is not for free. I have chosen it for three main reasons:
1. It is the software I knew better when I started to look for a new mesher;
2. It has a direct Pointwise -> OpenFOAM export
3. It has a good way to handle with cyclic patches, that is an important feature for me.
That's it. However, I have not too much experience with other commercial grid mesher: only a couple of meshes with Gambit and with GridPro. And some (bad) experience with salome.

Ok, thanks

Originally Posted by maddalena

Thus are you not him???

Sorry, hope this doesn't disappoint you too much!

Best Regards

Vesselin

[alberto]

Originally Posted by vkrastev

Alberto, if this is a suggestion for me, thank you too, but the leastSquares option (whether limited or not) does not seem to give any benefits in my case (I don't know if it's something about the OF version: you and another guy of the forum started a little discussion about it in the tread concerning the second order schemes, but I didn't understand if the leastSquares option is well implemented in all the newest OF versions, namely from the 1.6 till now, or not). Till today the best combination I've found for the fvSchemes is:

The answer was for both of you. The leastSquares scheme for gradients ensures second order accuracy on arbitrary grids.

The implementation is different in OF from OpenCFD and in -dev/-extend, since the weights are "area based" in the OpenCFD version, and distance based (which is standard) in -dev/-extend.

Best,

[vkrastev]

Originally Posted by alberto

The leastSquares scheme for gradients ensures second order accuracy on arbitrary grids.

But does it assure also stability? For my case (you could see tons of details about it here http://www.cfd-online.com/Forums/ope...r-schemes.html ), and with the OpenCFD implementation, it doesn't seem so...

Originally Posted by alberto

The implementation is different in OF from OpenCFD and in -dev/-extend, since the weights are "area based" in the OpenCFD version, and distance based (which is standard) in -dev/-extend.

What do you mean with "standard"? Better accuracy or stability? Or simply more common implementation form?

Thanks

Vesselin

[alberto]

Originally Posted by vkrastev

But does it assure also stability? For my case (you could see tons of details about it here http://www.cfd-online.com/Forums/ope...r-schemes.html ), and with the OpenCFD implementation, it doesn't seem so...

The problem discussed in this thread is related to accuracy, since you cannot match results.

Usually Gauss linear is more stable than leastSquares. If you want to have a distance-based leastSquares in OpenCFD implementation, you can use extendedLeastSquares.

What do you mean with "standard"? Better accuracy or stability? Or simply more common implementation form?

Standard = "as per textbook"

Best,

[vkrastev]

Originally Posted by alberto

The problem discussed in this thread is related to accuracy, since you cannot match results.

Yes, but more accuracy=using second order convection schemes=problems (lot of problems) with stability on tetrahedral meshes

Originally Posted by alberto

Usually Gauss linear is more stable than leastSquares.

That is exactly what I have noticed in my runs

Originally Posted by alberto

If you want to have a distance-based leastSquares in OpenCFD implementation, you can use extendedLeastSquares.

Ok, thanks. But if also this implementation has stability problems compared with Gauss linear, I would still prefer the Gauss linear (maybe limited) itself: better some not-so-accurate results than no results at all...

Originally Posted by alberto

Standard = "as per textbook"

Got it

Thanks for all the comments

Vesselin

[alberto]

I asked already elsewhere, but is the mesh quality low (what does checkMesh say?).

Hint: hex-dominant meshes are so nice ;-)

[vkrastev]

Originally Posted by alberto

I asked already elsewhere, but is the mesh quality low (what does checkMesh say?).

Mesh stats
points: 357845
faces: 3218365
internal faces: 3105296
cells: 1527609
boundary patches: 10
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 0
prisms: 213225
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 1314384
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
symmetry 22600 12584 ok (non-closed singly connected)
floor 14660 7609 ok (non-closed singly connected)
inlet 426 242 ok (non-closed singly connected)
outlet 432 245 ok (non-closed singly connected)
side 2228 1204 ok (non-closed singly connected)
top 1648 910 ok (non-closed singly connected)
body 54899 27768 ok (non-closed singly connected)
nose 8704 4461 ok (non-closed singly connected)
slant 3948 2058 ok (non-closed singly connected)
back 3524 1841 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-1.26 0 0.1945) (6.27 1.44 1.1945)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (1.709e-17 -1.03646e-15 -2.57399e-16) OK.
Max cell openness = 3.24287e-16 OK.
Max aspect ratio = 5.97752 OK.
Minumum face area = 1.71072e-06. Maximum face area = 0.0159908. Face area magnitudes OK.
Min volume = 1.10751e-09. Max volume = 0.000575106. Total volume = 10.7878. Cell volumes OK.
Mesh non-orthogonality Max: 54.8744 average: 14.5203
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 1.98187 OK.

Mesh OK.

End

Originally Posted by alberto

Hint: hex-dominant meshes are so nice ;-)

I agree , but: 1) OpenFOAM is explicitly designed to handle arbitrarly shaped cells, so I would expect to reach at least decent results with a prisms-tetraherdons mesh; 2) To my knowledge and skills, unstructured tetra-dominant meshes are much easier and faster to generate around complex geometries and those features make them more "industrial-user" friendly...Out of curiosity, can you suggest me a fast way to generate (good) hexa-dominant meshes?

Thanks

Vesselin

[alberto]

Hi,

the mesh is OK.

I agree , but: 1) OpenFOAM is explicitly designed to handle arbitrarly shaped cells, so I would expect to reach at least decent results with a prisms-tetraherdons mesh;

That should be possible.
The -extend 1.6 release has the reconCentral scheme, which should improve this. Some time ago I took the freedom of compiling it for 1.7.x (see attachment). You can use it as interpolation scheme (add the library to controlDict) with the cellLimited option for gradients.

2) To my knowledge and skills, unstructured tetra-dominant meshes are much easier and faster to generate around complex geometries and those features make them more "industrial-user" friendly...Out of curiosity, can you suggest me a fast way to generate (good) hexa-dominant meshes?

It depends on the meshing tools you have. ICEM can do that, Harpoon does that, CD-Adapco has a tool to do that too. OpenFOAM has snappyHexMesh, which is a bit painful to use, if your geometry has a lot of borders that have to be well defined.

Best,

[vkrastev]

Originally Posted by alberto

Hi,

the mesh is OK.



That should be possible.
The -extend 1.6 release has the reconCentral scheme, which should improve this. Some time ago I took the freedom of compiling it for 1.7.x (see attachment). You can use it as interpolation scheme (add the library to controlDict) with the cellLimited option for gradients.



It depends on the meshing tools you have. ICEM can do that, Harpoon does that, CD-Adapco has a tool to do that too. OpenFOAM has snappyHexMesh, which is a bit painful to use, if your geometry has a lot of borders that have to be well defined.

Best,

Thanks a lot, I'll try to compile this reconCentral scheme and than see what happens! By the way, nowadays I use ANSA (for surface meshing and for constructing the prism-layer) and Tgrid (for the rest of the volumetric mesh) as primary meshing tools...Some time ago I was obliged to use ICEM for my master's thesis, and indeed I found it a very powerful (but also not-so-user-friendly) tool...

Thank you once again

Best Regards

Vesselin

[bastil]

Originally Posted by vkrastev

By the way, nowadays I use ANSA (for surface meshing and for constructing the prism-layer) and Tgrid (for the rest of the volumetric mesh) as primary meshing tools...

Interesting combination. Why are you doing it this way?

[aerothermal]

Originally Posted by mitja_morgut

Hi Maddalena,

from your profile I have noticed that you are working in Trieste.

I am also from Trieste.

Recently I have compared CFX-11 and OF-1.5 for prediction of the flow around NACA0012.

If you are interested to contact me, (to arrange a meeting in TS) you can find my e-mail address in the profile.

Have a nice day

Mitja

Hello Mitja,

Could you post your fvSolution and fvSchemes as well as your control dict for the case of NACA0012 aifoil? Do you have any picture showing the convergence history?

Regards,

Guilherme

[aerothermal]

Dear Maddalena,

Have you managed to solve your convergence issues?
Could you post your fvSolution, fvSchemes, controlDict?
I am trying to simulate a cylinder M=0.07 and Re=2.2E5 with heat transfer over a fully rough wall with rhoSimpleFoam.

Regards,

Guilherme

[maddalena]

Originally Posted by aerothermal

Dear Maddalena,

Have you managed to solve your convergence issues?
Could you post your fvSolution, fvSchemes, controlDict?
I am trying to simulate a cylinder M=0.07 and Re=2.2E5 with heat transfer over a fully rough wall with rhoSimpleFoam.

Regards,

Guilherme

Well,
I solved the problem posted above, and was not (only) a problem of fvSchemes and fvSolution. In any case, the right setup is not unique and must be refined for your case, that is indeed really different from what I have. A suggestion: if your solution does not converge, it is probably a matter of BC that are not correctly tuned.
Enjoy

mad

[vkrastev]

Originally Posted by bastil

Interesting combination. Why are you doing it this way?

Hi Bastil,
my main problem is that I use an old version of ANSA which has some difficulties to manage volumetric meshes above 3-3.5 milions of cells (this is, I guess, a kind of "communication bug" between the software and the RAM memory of the PC...I know that the latest 64-bit versions of ANSA do not have such a trouble)...So, if my problem grows up above this limit, I just have to switch to another meshing software In any case, I do prefer to manage wiith the surface mesh and the prisms b.l. with ANSA, and then fill the remaining volume with tetras using Tgrid: it's a matter of personal taste, simply I don't like how Tgrid deals with surface meshing and b. l. building...

Best Regards

Vesselin