[x86_64leon]

Dear All,

Has anybody tried to run the cavity tutorial on different kinds of meshes ?

We have tried 3 kinds of meshes :
1- Structured mesh created by blockMesh
2- Diagonalized mesh (structured mesh where all hexa cells are splitted in diagonal)
3- Unstructured mesh

The exact same fields, boundary conditions, fvSchemes and fvSolution are used for all meshes. ,Different schemes have been tried without improving results.

Meshes are compared on the basis of velocity profiles along the cavity centerline, either vertical or horizontal. The profiles are extracted on faces intersections using sample (see sampleDict).

Plots show that velocity profiles are :
- Unstructured and structured meshes are somehow close to each other
- Unstructured mesh experiences lots of oscillations
- Diagonalized mesh solution is far from the structured solution, even though the diagonalized mesh is just the structured mesh that has been splitted.

Full cases are joined in this post.

[x86_64leon]

Case files can be downloaded from there :

http://dl.free.fr/oUttm6S6Z

[hk318i]

I Think you results are generally fine and these wired results due to two main reasons

• The interpolation scheme in sampleDict and the set type.
• From your plots, the fluctuations appear only when you plot the velocity component in the direction of the centreline. (u vs Horizontal line or v vs vertical line).

I downloaded you case and tested these two potential reasons.
First I modified sampleDict as follows

setFormat raw;

surfaceFormat vtk;

interpolationScheme cellPoint;

fields
(
    U
);


sets
(
    centerline_v
    {
        type    uniform;
        axis        distance;

        start       (0.05 -0.0000000000001 0.005);
        end         (0.05  0.1000000000001 0.005);
        nPoints 100;
    }
    centerline_h
    {
        type    uniform;
        axis        distance;

        start       (-0.0000000000001 0.05 0.005);
        end         ( 0.1000000000001 0.05 0.005);
        nPoints 100;
    }
);


surfaces
(

);

and here are the results (unstructure mesh) against centerline_v (Fig1a and Fig1b). It is clear that the results looks much better with much less fluctuations.

Also I plotted u against the vertical line and v against the horizontal line to see the velocity profiles (Fig2). It shows that the results are following the general trend for this case.

Please keep in mind that these results still are not validated. You will find in literature a lot of numerical and experimental results for this case for Re 5000 and higher. I think if your case is the original cavity tutorial, Re is less than 1000.

PS:
Here is gnuplot script to recreate fig2 if you need it

#!/usr/bin/gnuplot -persist
reset
set terminal pngcairo size 750,720 enhanced font 'Verdana,12'
set out "Fig2.png"

set yzeroaxis
set x2zeroaxis
set xrange [-1:1]
set yrange [0:1]
set x2range [0:1]
set y2range [-1:1]
set x2tics
set y2tics
set key l

set xlabel 'u'
set x2label 'x'
set ylabel 'y'
set y2labe 'v'

d= 0.1
Ux = 1.0

plot "centerline_v_U.xy" u ($2/Ux):($1/d) w l lw 2 t "Vertical, u",\
     "centerline_h_U.xy" u ($1/d):($3/Ux) w l axes x2y2 lw 2 t "Horizontal, v"

[x86_64leon]

Dear hk318i,

Thanks a lot for your constuctive reply.

I have modified the sampleDict following only one of your remark. The change to uniform sampling does not seem to be necessary.
I have changed the interpolation scheme from :

interpolationScheme cell;

to

interpolationScheme cellPoint;

And the oscillations in the unstructured mesh curves have almost totally disappeared.
See updated curves.

However, results from the diagonalized mesh still show some large differences when compared to the structured mesh.

[hk318i]

Regarding the diagonalized mesh, I think more investigations are required to clarify few points.

• It should be confirmed that the results from the three cases are reaching steady state solution. It could be confirmed by a velocity probes at different locations.
• A benchmark case is required or at least a grid independence study using the structured mesh till the steady state solution. Simply there is no prof that the current structure mesh result is correct one.
• Changing the grid type could require different numerical scheme.

I know the cavity case looks a straight forward standard case but it isn't. I would recommend Erturk paper specially his review "Discussions On Driven Cavity Flow".
http://arxiv.org/pdf/cs/0411048.pdf

Unfortunately, I don't have specific recommendations about the mesh type and the numerical scheme. I will be happy to hear from other users in this forum and from you about any further results.

[x86_64leon]

Concerning the numerical schemes, different solutions have been tried to improve the diagonalized mesh results without success. If any other user has some hints to propose better fvSchemes or fvSolution for unstructured meshes, they will be welcome.


Even though not converged at zero machine, computations are rather converged at time t=5. The residual are shown on attached figures.

[hk318i]

I agree with you the residuals looks very good but if I were you, I would rerun the diagonal case with velocity probes a different location to ensure that the solution reached the steady state. Sometimes, the residuals are deceiving. Hopefully someone will join this thread soon. Keep us updated.

[x86_64leon]

Dear Foamers,

It seems that using "corrected" numerical schemes instead of "orthogonal" improves drastically the results, especially on the diagonalized mesh.

The idea is to modify the system/fvSchemes as follows for the laplacianSchemes :

Replace

laplacianSchemes
{
default Gauss linear orthogonal;
}

by

laplacianSchemes
{
default Gauss linear corrected;
}


And similarly for the snGradSchemes, replace :

snGradSchemes
{
default orthogonal;
}

by

snGradSchemes
{
default corrected;
}



In the PISO algorithm settings (see fvSolution), we also suggest to increase the number of non orthogonal correctors to :


PISO
{
nCorrectors 2;
nNonOrthogonalCorrectors 2;
pRefCell 0;
pRefValue 0;
}

I attached a zip containing velocity profiles along horizontal and vertical lines.
The files named "corrected" correspond to the above corrections.
Images are plot exactly with the same axis ranges, in order to ease comparisons.

[squick]

The problem of icoFoam to handle the wall driven cavity was originally encountered on Friedrich-Keller non uniform meshes while X86_64Leon has used FK uniform meshes for his post on CFD Online.
Several settings of the parameters have been investigated, including the "corrected" one. Here are results on a 81x81 non uniform mesh and the three following settings.
laplacianSchemes
{
default Gauss linear corrected;//limited 0.333;//orthogonal;
}
PISO
{
nCorrectors 2;
nNonOrthogonalCorrectors 2;
pRefCell 0;
pRefValue 0;
}
The setting "corrected" clearly provides better results than the setting "orthogonal". Neverthelesse they are still far from the reference solution while other codes already are on it at the 41x41 mesh level.
What is euphemistically called mesh sensitivity appears to be in fact a more serious problem of convergence on FK and unstructured meshes.

[markusrehm]

Hi,

not sure about it but maybe check this:

http://www.cfd-online.com/Forums/ope...dtphicorr.html

One of the guys (Ville) also studied a cavity in detail.

Markus

[squick]

Thanks for your reply. Very few information exists on the DdtPhiCorr , the term used to stabilize the incompressible algorithms. I have found this link, https://github.com/asimonder/projectionFoam
but it does not seems to improve the results.

I have also quickly tried to incorporate fourth order derivatives of the pressure like it is done for instance in J.C.P. 258, pp. 880-914, 2014.
It didn't also improve the results but it has been done explicitly and i wonder if an implicit implementation would better work

[markusrehm]

Hi Gerard,

are you aware of this thread?

http://www.cfd-online.com/Forums/ope...mesh-pipe.html

Markus

[thomasArk47]

Gerard,

here is a short picture of the convergence results I have obtained for the cavity case on the FK meshes (those of Gerard).

As you can see, there is no noticeable problem of convergence. Somewhat slow but it is a well-known fact.

Note also that I have done no effort to use the best numerical parameters. Quite standard here (somewhat similar to the x86-64 ones).

Maybe you should give me your exact case in order I check your datas. And which version of OF are you using.

To conclude, I am agree that OF has some weaknesses from a strict numerical point of view but these are far from being as important as one could believe at a first glance.