[ivan_cozza]

I'm working with a NACA0012 airfoil, and I have to choose between blockmesh and another mesher.
Is blockmesh capable to handle a C type mesh (a mesh with one cut inside)?

[wolle1982]

Hi,

late answer. But yes. BlockMesh is great for an 2D airfoil. Once created you can easily change Mesh settings within seconds. I wrote a scripted tool that reads any Airfoil and creates a blockMeshDict.

[ivan_cozza]

Really?
Can you post some wing profile mesh produced with this code? I'm struggling so much with wing profile meshes for RANS and LES calculations, so a tool like this could be wonderful!

[reza]

Hi Wolfgang,
Can you please post your scrpit which is a very useful toll for me.
Thanks alot

[wolle1982]

Sorry, legend doesn't look good.

sort it by yourself.

each "|" has to be under/over a e.g. 4/5
The wing leading/trailing edge is 20/21 and 16/17
10/11 is the front-middle vertex of the grid.
the even nubers are always in the top layer, the uneven numbers in the lower layer (here: z=5)

@MR Amiralaei: if you are unfamiliar with VBA, only find the vertices of your airfoil that represent the trail/leadingedge and the t/2 vertex on the upper and lower side (those will be vertex 18/19 and 22/23). the splinevertices in between are defining the splines from e.g. 16 to 18, 18 to 20, 20 to 22, 22 to 16 and so on.

[ivan_cozza]

@ Wolfgang:

I performed a checkMesh to your mesh and I found:

***High aspect ratio cells found, Max aspect ratio: 1.08535e+06, number of cells 11803
<<Writing 11803 cells with high aspect ratio to set highAspectRatioCells
Minumum face area = 4.7119e-09. Maximum face area = 11.7362. Face area magnitudes OK.
Min volume = 2.35595e-10. Max volume = 0.586809. Total volume = 162.175. Cell volumes OK.
Mesh non-orthogonality Max: 79.1865 average: 23.0154
*Number of severely non-orthogonal faces: 9.
Non-orthogonality check OK.
<<Writing 9 non-orthogonal faces to set nonOrthoFaces

How good are the results with this mesh? I suppose that the AR error is not important (it depends on the BL stretching), but I have some doubt with the non-Hortogonality error, maybe some more blocks are needed...

Another question, your script produce the whole blockMeshDict, with cell number, stretching factors and patches, or just the spline points?

In any case, good job!

[reza]

Wolfgang,
Thank you for posting your mesh. Good job

[ivan_cozza]

Also if you select the BL as a separate block you will continue to have severe H.A.R., as your points along the profile cannot be more than now, but maybe you will have a better level of horto.
In any case, defining the BL in a separate block can be usefull to spare cells!
And, yes, maybe your stability problems depend on the non-hortogonality, maybe you can try with different nuerical schemes...

[wolle1982]

thanks for the answer.

I already tried with different numerical schemas. The difference is not very great. What I just found out is way more interessting:

I'm running on a machine with 8 Processors. Stability is very very sensitive to the used number of Processors. A calculation on 8 parallel running chips leaded to a divergence within 20sec. running on only 2 processors did a good job and held the CoNum very even and low.

[ivan_cozza]

By the way, can you post your fvSchemes, fvSolution , decomposePar and B.C. definition?
It seems very strange to me that the stability depends on the number of subdomains employed...

[norman1981]

Dear Ivan,

I might be wrong but the stability could be affected by the number of subdomains employed.
If you try to simulate something and you change the number of subdomains you could also see some differences on the final result.
This behaviour is well known in the HPC field and it is related to the way your code access memory and broadcasts data. It is something similar to the "butterfly effect"... you start with a little error and it grows as the simulation goes on.
It can be limitated for example forcing your main process to broadcast constants at every time step and not at very beginning of your simulation and reducing your time step... but I reaffirm: I might be wrong :-) !

Regards

Norman

[wolle1982]

fvschemas
ddtSchemes
{
default Euler;
}

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

divSchemes
{
default Gauss linear;
div(phi,U) Gauss limitedLinearV 1;
div(phi,k) Gauss limitedLinear 1;
div(phi,epsilon) Gauss limitedLinear 1;
div(phi,R) Gauss limitedLinear 1;
div(R) Gauss linear;
div(phi,nuTilda) Gauss limitedLinear 1;
div((nuEff*dev(grad(U).T()))) Gauss linear;
}

laplacianSchemes
{
default none;
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;
laplacian(DREff,R) Gauss linear corrected;
laplacian(DnuTildaEff,nuTilda) Gauss linear corrected;
}

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

snGradSchemes
{
default corrected;
}

fluxRequired
{
default no;
p;
}

==========================================
fvsolution

p ICCG 1e-09 0;
U BICCG 1e-09 0;
k BICCG 1e-09 0;
epsilon BICCG 1e-09 0;
R BICCG 1e-09 0;
nuTilda BICCG 1e-09 0;
}

PISO
{
momentumPredictor yes;
nCorrectors 1;
nNonOrthogonalCorrectors 0;
pRefCell 0;
pRefValue 0;
}
==================================================
boundaries

boundaryField
{
Outlet
{
type zeroGradient;
}
ObenAndUnten
{
type symmetryPlane;
}
Inlet
{
type fixedValue;
value uniform (80 0 0);
}
Wing
{
type fixedValue;
value uniform (0 0 0);
}
Front
{
type empty;
}
Back
{
type empty;
}
}
==================================================
simple decomposing!
=================================================

@ Norman Del Puppo

for testing I did some simple cases.
a very simple box with 100x100 cells. equaly simple-decomposed to 2, 4 and 8 processors. running good with 1, 2 and 8. got divergend after half to be calculated with 4 processors.

making it more complex (simpleGrading 1000 1000 1) points out, that the more CPUs one runs the more instable the calculation is.

Any comments on that?

[ivan_cozza]

@ Norman Del Puppo

I'm not an HPC expert, but your arguments seems correct.

@ Wolfgang

If I've understood, the test case is good with 1,2 and 8 cpu but fails with 4?

[wolle1982]

All right. Our PC has 2 CPU with each 4 Kernels. So maybe this is one reason for the bad floatTransfer.

And yes, after redefining the BoundaryLayer as separate blocks/hexs I was able to refine the BL enough to get very accurate values for cd and cl. and this only with a number of cells of 16800...!