CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Weird results on Cavity and unstructured meshes

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   July 20, 2015, 08:36
Default Weird results on Cavity and unstructured meshes
  #1
New Member
 
Lionel GAMET
Join Date: Nov 2013
Location: Lyon
Posts: 10
Rep Power: 5
x86_64leon is on a distinguished road
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 is offline   Reply With Quote

Old   July 20, 2015, 08:53
Default With the files ...
  #2
New Member
 
Lionel GAMET
Join Date: Nov 2013
Location: Lyon
Posts: 10
Rep Power: 5
x86_64leon is on a distinguished road
Case files can be downloaded from there :

http://dl.free.fr/oUttm6S6Z
Attached Images
File Type: jpg velocity_horizontalprofile_50%.jpg (22.9 KB, 96 views)
File Type: jpg velocity_verticalprofile_50%.jpg (24.0 KB, 77 views)
x86_64leon is offline   Reply With Quote

Old   July 21, 2015, 06:45
Default
  #3
Senior Member
 
Hassan Kassem
Join Date: May 2010
Location: UK
Posts: 231
Rep Power: 10
hk318i is on a distinguished road
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
Code:
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
Code:
#!/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"
Attached Images
File Type: jpg Fig1a.jpg (17.3 KB, 53 views)
File Type: jpg Fig1b.jpg (19.1 KB, 45 views)
File Type: jpg Fig2.jpg (23.5 KB, 48 views)
hk318i is offline   Reply With Quote

Old   July 21, 2015, 10:24
Default
  #4
New Member
 
Lionel GAMET
Join Date: Nov 2013
Location: Lyon
Posts: 10
Rep Power: 5
x86_64leon is on a distinguished road
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.
Attached Images
File Type: jpg velocity_horizontalprofile_50%.jpg (21.8 KB, 43 views)
File Type: jpg velocity_verticalprofile_50%.jpg (22.2 KB, 44 views)
x86_64leon is offline   Reply With Quote

Old   July 21, 2015, 11:23
Default
  #5
Senior Member
 
Hassan Kassem
Join Date: May 2010
Location: UK
Posts: 231
Rep Power: 10
hk318i is on a distinguished road
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.
hk318i is offline   Reply With Quote

Old   July 22, 2015, 04:32
Default
  #6
New Member
 
Lionel GAMET
Join Date: Nov 2013
Location: Lyon
Posts: 10
Rep Power: 5
x86_64leon is on a distinguished road
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.
Attached Images
File Type: jpg convergence_velocity.jpg (21.2 KB, 45 views)
File Type: jpg convergence_pressure.jpg (24.7 KB, 55 views)
x86_64leon is offline   Reply With Quote

Old   July 22, 2015, 07:15
Default
  #7
Senior Member
 
Hassan Kassem
Join Date: May 2010
Location: UK
Posts: 231
Rep Power: 10
hk318i is on a distinguished road
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.
hk318i is offline   Reply With Quote

Old   August 31, 2015, 08:10
Default
  #8
New Member
 
Lionel GAMET
Join Date: Nov 2013
Location: Lyon
Posts: 10
Rep Power: 5
x86_64leon is on a distinguished road
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.
Attached Files
File Type: zip velocity_profile_50%--constantCFL.zip (65.1 KB, 11 views)
x86_64leon is offline   Reply With Quote

Old   August 31, 2015, 11:14
Default
  #9
New Member
 
Gerard
Join Date: Dec 2014
Posts: 7
Rep Power: 4
squick is on a distinguished road
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.
Attached Images
File Type: png diag3_corrected.png (5.5 KB, 57 views)
File Type: png diag3_limited0333.png (5.6 KB, 40 views)
File Type: png diag3_orthogonal.png (5.6 KB, 44 views)

Last edited by squick; September 1, 2015 at 09:10.
squick is offline   Reply With Quote

Old   September 7, 2015, 07:56
Default
  #10
Senior Member
 
Markus Rehm
Join Date: Mar 2009
Location: Erlangen (Germany)
Posts: 182
Rep Power: 9
markusrehm is on a distinguished road
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
markusrehm is offline   Reply With Quote

Old   September 7, 2015, 08:58
Default Brezi Babuska
  #11
New Member
 
Gerard
Join Date: Dec 2014
Posts: 7
Rep Power: 4
squick is on a distinguished road
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
squick is offline   Reply With Quote

Old   September 10, 2015, 11:00
Default
  #12
Senior Member
 
Markus Rehm
Join Date: Mar 2009
Location: Erlangen (Germany)
Posts: 182
Rep Power: 9
markusrehm is on a distinguished road
Hi Gerard,

are you aware of this thread?

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

Markus
markusrehm is offline   Reply With Quote

Old   March 1, 2016, 20:44
Default convergence for cavity case
  #13
Member
 
Thomas Boucheres
Join Date: May 2013
Posts: 41
Rep Power: 5
thomasArk47 is on a distinguished road
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.
Attached Images
File Type: png validation_v1.png (40.8 KB, 29 views)

Last edited by thomasArk47; March 3, 2016 at 16:12.
thomasArk47 is offline   Reply With Quote

Reply

Tags
cavity, mesh, openfoam, structured, unstructured

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unstructured Mesh for Cavity saeedjack Main CFD Forum 7 August 9, 2012 14:55
Lid driven cavity ganesh Main CFD Forum 0 August 5, 2009 20:33


All times are GMT -4. The time now is 08:04.