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

fvScheme and NonOrthogonal Correctors

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

Like Tree7Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   April 1, 2011, 07:04
Default fvScheme and NonOrthogonal Correctors
  #1
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
Hi all,
I have to run a simulation with a mesh of prisms and hexas. This is my checkMesh:

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 101178
internal points: 0
faces: 259884
internal faces: 118566
cells: 69762
boundary patches: 6
point zones: 0
face zones: 0
cell zones: 1

Overall number of cells of each type:
hexahedra: 29640
prisms: 40122
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
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
obstacle 1560 3120 ok (non-closed singly connected)
bottom 49 100 ok (non-closed singly connected)
right 68 138 ok (non-closed singly connected)
top 49 100 ok (non-closed singly connected)
left 68 138 ok (non-closed singly connected)
defaultFaces 139524 101178 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0 0 0) (0.00447 0.0062 5e-05)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (1.63471e-19 -2.90979e-18 -4.90414e-20) OK.
Max cell openness = 2.19738e-16 OK.
Max aspect ratio = 13.3858 OK.
Minumum face area = 8.1356e-11. Maximum face area = 7.04863e-09. Face area magnitudes OK.
Min volume = 4.0678e-15. Max volume = 3.16076e-13. Total volume = 1.21253e-09. Cell volumes OK.
Mesh non-orthogonality Max: 31.2939 average: 4.74797
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.495827 OK.

Mesh OK.


What are the best setting for fvScheme and non-orthogonal corrector? Is the option "limited 0.5" a good choise? Something like this:

Code:
gradSchemes
{
    default         cellLimited Gauss linear 1;
}

laplacianSchemes
{
    default         Gauss linear limited 0.5;
}
snGradSchemes
{
    default         limited 0.5;
}

And for the divergence what i have to choose? (Iam using interFoam)
divSchemes
{
div(rho*phi,U) ??
div(phi,alpha) ??
div(phirb,alpha) ??
}

and finally for the non orthogonal corrector in fvSolution, what is best choise?

Thanks for any help

andrea
Andrea_85 is offline   Reply With Quote

Old   April 1, 2011, 08:19
Default
  #2
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Your mesh has a good quality, so probably it would not be necessary to limit so much the gradients, neither to use a lot of non orthogonal correctors. I would suggest this setting as a first try:

GradSchemes: cellMDLimited Gauss linear 0.5
divSchemes(for "rho*phi,U"): Gauss linearUpwindV cellMDLimited Gauss linear 0.5
divSchemes(others): Gauss upwind
LaplacianSchemes: the same as in your post
SnGradSchemes: as above
nNonOrthogonalCorrectors: 1

Regards

V.
vkrastev is offline   Reply With Quote

Old   April 1, 2011, 08:31
Default
  #3
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
Thanks for reply Vesselin,
what is the difference between
cellMDLimited and cellLimited?

However I will try your settings to see if it's good!

Thanks again

andrea
Andrea_85 is offline   Reply With Quote

Old   April 1, 2011, 08:37
Default
  #4
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by Andrea_85 View Post
Thanks for reply Vesselin,
what is the difference between
cellMDLimited and cellLimited?

However I will try your settings to see if it's good!

Thanks again

andrea
As far as I know, cellMDLimited is less "brutal" than cellLimited, because the former applies a separate limiting depending on the direction (MD stands for Multi-Dimensional), while the latter applies the same cell-based limiter for the gradient in all directions (which means that sometimes it probably limits something that has no need to be limited)

Regards

V.
vkrastev is offline   Reply With Quote

Old   April 5, 2011, 05:50
Default
  #5
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
Hi Vesselin,
i tried your suggestions in a simple test-case: the relaxation of a square drop. With an orthogonal mesh i can find the analytical solution without any problems. Then i tried to run the same case with a mesh made of prisms, but the results are very bad. The drop starts to deform in a non-physical way (it should be circular) until it exits from the domain.

Here my "checkMesh -allTopology -allGeometry". as you can see there is one failed check, while only "checkMesh" is ok (i checked it also in the previous post geometry and i got the same error, the mesh is build up with gmsh). maybe is that the problem? or have i to increase the limit on the schemes?

Time = 0

Mesh stats
points: 32734
internal points: 0
edges: 113611
internal edges: 15891
internal edges using one boundary point: 0
internal edges using two boundary points: 15891
faces: 113134
internal faces: 48146
cells: 32256
boundary patches: 2
point zones: 0
face zones: 0
cell zones: 1

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

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
<<Writing 476 cells with with single non-boundary face to set twoInternalFacesCells
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology Bounding box
atm 476 952 ok (non-closed singly connected) (0 0 0) (0.06 0.06 0.001)
defaultFaces 64512 32734 ok (non-closed singly connected) (0 0 0) (0.06 0.06 0.001)

Checking geometry...
Overall domain bounding box (0 0 0) (0.06 0.06 0.001)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (2.27697e-19 -9.96175e-20 0) OK.
Max cell openness = 2.1596e-16 OK.
Max aspect ratio = 10.4958 OK.
Minumum face area = 5.28134e-08. Maximum face area = 7.05771e-07. Face area magnitudes OK.
Min volume = 5.28134e-11. Max volume = 2.09285e-10. Total volume = 3.6e-06. Cell volumes OK.
Mesh non-orthogonality Max: 30.8774 average: 6.37461
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.521316 OK.
Min/max edge length = 0.000311967 0.001 OK.
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : average = 1 min = 1
All face flatness OK.
Cell determinant (wellposedness) : minimum: 0 average: 4.26433e-35
***Cells with small determinant found, number of cells: 32256
<<Writing 32256 under-determined cells to set underdeterminedCells

Failed 1 mesh checks.

End


Thanks

andrea
Andrea_85 is offline   Reply With Quote

Old   April 5, 2011, 08:54
Default
  #6
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by Andrea_85 View Post
Hi Vesselin,
i tried your suggestions in a simple test-case: the relaxation of a square drop. With an orthogonal mesh i can find the analytical solution without any problems. Then i tried to run the same case with a mesh made of prisms, but the results are very bad. The drop starts to deform in a non-physical way (it should be circular) until it exits from the domain.

Here my "checkMesh -allTopology -allGeometry". as you can see there is one failed check, while only "checkMesh" is ok (i checked it also in the previous post geometry and i got the same error, the mesh is build up with gmsh). maybe is that the problem? or have i to increase the limit on the schemes?

Time = 0

Mesh stats
points: 32734
internal points: 0
edges: 113611
internal edges: 15891
internal edges using one boundary point: 0
internal edges using two boundary points: 15891
faces: 113134
internal faces: 48146
cells: 32256
boundary patches: 2
point zones: 0
face zones: 0
cell zones: 1

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

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
<<Writing 476 cells with with single non-boundary face to set twoInternalFacesCells
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology Bounding box
atm 476 952 ok (non-closed singly connected) (0 0 0) (0.06 0.06 0.001)
defaultFaces 64512 32734 ok (non-closed singly connected) (0 0 0) (0.06 0.06 0.001)

Checking geometry...
Overall domain bounding box (0 0 0) (0.06 0.06 0.001)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (2.27697e-19 -9.96175e-20 0) OK.
Max cell openness = 2.1596e-16 OK.
Max aspect ratio = 10.4958 OK.
Minumum face area = 5.28134e-08. Maximum face area = 7.05771e-07. Face area magnitudes OK.
Min volume = 5.28134e-11. Max volume = 2.09285e-10. Total volume = 3.6e-06. Cell volumes OK.
Mesh non-orthogonality Max: 30.8774 average: 6.37461
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.521316 OK.
Min/max edge length = 0.000311967 0.001 OK.
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : average = 1 min = 1
All face flatness OK.
Cell determinant (wellposedness) : minimum: 0 average: 4.26433e-35
***Cells with small determinant found, number of cells: 32256
<<Writing 32256 under-determined cells to set underdeterminedCells

Failed 1 mesh checks.

End


Thanks

andrea
Hi Andrea, can you post some more information about the case (images of the domain configuration and of the constructed mesh will be appreciated)? For now I can only say that these messages coming from the checkMesh report are quite strange (never seen them before...)

Regards

V.
vkrastev is offline   Reply With Quote

Old   April 5, 2011, 09:26
Default
  #7
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
Hi Vesselin.

I have attached my test case. The structured grid has 22550 cells (all hexa, i found convergence to the analytical solution also with 3600 cells) and the unstructured one has 32256 cells (all prisms). The BC are the same in both case. I have also included the fvScheme and fvSolution for both cases. The dimensions of the domain are 6cmx6cm. The analytical solution is a drop of radius 2cm.

as you can see from the movie the solution of the unstructured case is very bad.
Any suggestion would be appreciated!

andrea
Andrea_85 is offline   Reply With Quote

Old   April 5, 2011, 09:26
Default
  #8
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
ops, i forgot the .zip!

andrea
Andrea_85 is offline   Reply With Quote

Old   April 5, 2011, 09:36
Default
  #9
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
There is still no .zip attachement...
vkrastev is offline   Reply With Quote

Old   April 5, 2011, 09:40
Default
  #10
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
sorry, was too large! Now is ok

andrea
Attached Files
File Type: zip Structure_fine.zip (60.1 KB, 52 views)
File Type: zip Unstructured.zip (87.8 KB, 53 views)
Andrea_85 is offline   Reply With Quote

Old   April 5, 2011, 10:12
Default
  #11
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Well, first of all the structured mesh seems much finer, and this is not "fair": you'll have to refine a lot the unstructured mesh and give it a second try with the same fvSchemes and fvSolution settings (but with cellMDLimited option instead of cellLimited). Secondly, if the results are still far from the structured mesh response, you can try to use also on the (fine) unstructured the following divSchemes (leaving the linearUpwindV scheme on velocity):

div(phi,alpha) Gauss vanLeer;
div(phirb,alpha) Gauss interfaceCompression;

Regards

V.
vkrastev is offline   Reply With Quote

Old   April 5, 2011, 10:46
Default
  #12
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
Thanks again for your patience.
I found good results also on a "less" fine structured grid (3600 hexa, 60X60 as in the attached). The unstructured mesh is almost 9 times more defined.
Note that the computational cost drastically increase in the unstructured case (few second for the structured mesh, 1h and a half for the unstructured case). So of course i can refine my unstructured mesh but is that the solution? I mean, Is the problem related to the "resolution" of the mesh, or to the selection of the right discretization schemes?..Or is there something else you have to take into account when you want to use an unstructured grid?

from what I know, OF should work fine on unstructured mesh...

However I will try to make the unstructured grid more fine and see what happens!

Thanks

Andrea
Attached Files
File Type: pdf mesh_60x60.pdf (18.0 KB, 128 views)
Andrea_85 is offline   Reply With Quote

Old   April 5, 2011, 10:46
Default
  #13
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hello Andrea,
Hi V, nice to hear you again.

As far as I know, tet mesh will never be comparable in term of convergence and accuracy to a hexa mesh. This is due to the way interpolation schemes work, thus nothing will change using a very very fine tet mesh. The only way to achieve the same accurcay is to use the reconCentral scheme, which is provided on 1.6-ext.

Andrea, maybe this discussion is useful for you: pressure eq. "converges" after few time steps. It applies to a mainly tet mesh. V also contributed to it.

cheers

mad
hua1015 likes this.
maddalena is offline   Reply With Quote

Old   April 5, 2011, 12:02
Default
  #14
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
Hi mad,
really really interesting thread!!..thanks for the hint. I would like to run some test using your and V. suggestions, changing the fvScheme and fvSolution and see what happens. However i'm using interFoam and i do not know if the right schemes for simpleFoam are good also for interFoam, but I'll do a check!

thanks again

andrea
Andrea_85 is offline   Reply With Quote

Old   April 6, 2011, 02:54
Default
  #15
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Quote:
Originally Posted by Andrea_85 View Post
i'm using interFoam and i do not know if the right schemes for simpleFoam are good also for interFoam, but I'll do a check!
Schemes and solution are connected on the way equations are solved, and are not connected with the physics of the problem. Thus I would say that, for similar terms, what is ok for a simpleFoam tet grid is ok for a interfoam tet grid. Please correct me if I am wrong...

mad
maddalena is offline   Reply With Quote

Old   April 6, 2011, 03:50
Default
  #16
Senior Member
 
Markus Rehm
Join Date: Mar 2009
Location: Erlangen (Germany)
Posts: 176
Rep Power: 8
markusrehm is on a distinguished road
Hi,

just a question from my side. Has anyone tried the recently published pointLinear scheme?

Quote from

https://github.com/OpenCFD/OpenFOAM-...2918f2e1bb7904


"surfaceInterpolation: New pointLinear scheme

First interpolates from the cells to the vertices and then from the face
vertices to the face centres. This may be a useful scheme for calculating
gradients on bad/tet meshes when used in conjunction with the Gauss gradient
scheme.
"

Regards. Markus.
fumiya and hua1015 like this.
markusrehm is offline   Reply With Quote

Old   April 7, 2011, 06:35
Default
  #17
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Hi all, just some additonal comments:

-For Andrea: as Mad said (nice to hear you too), tet meshes will never be exactly as accurate as hex ones. However, this not means that a cfd code cannot reach some remarkably good results with tetra (and, in general, unstructured) meshes, and OF indeed can (at least to my experience). Refining the mesh (whatever the type) will always improve accuracy, but of course this is not a universal solution to all problems (especially when you have a combination of stability and accuracy issues). When I suggested you to refine the unstructured mesh I was not really aware that it was so much finer than the hexa one, and of course a 9-times finer tetra mesh is far enough with the respect to the hexa one...Anyway, the "trik" whit the unstructured meshes is, provided a sufficiently good mesh quality (which means no highly skewed cells neither too strong non-orthogonality), to find the most reasonably good fvSchemes/Solution setting, which unfortunately tends to vary with the type of problem that has to be solved (compressible/incompressible, laminar/turbulent, multiphase, reacting and/or burning flows, etc.).

-For Mad (and Andrea too): I don't think the proper fvSchemes/Solution setting could be the same for very different kind of problems (thus, of physical quantities that have to be solved). For instance, I suggested to Andrea a setting which worked very well for incompressible High-Re turbulent flows (my case), but for his multiphase problem they seemed not so good...In addition, I tried the reconCentral scheme, but honestly it does not seem a so extraordinary improvement: in my computations there were practically no differences between results obtained with the reconCentral scheme and, for instance, the linearUpwind scheme with poperly set limiters on gradients.

Best Regards

V.
vkrastev is offline   Reply With Quote

Old   April 8, 2011, 03:26
Default
  #18
Senior Member
 
Andrea Ferrari
Join Date: Dec 2010
Posts: 275
Rep Power: 7
Andrea_85 is on a distinguished road
Hi V., mad and Markus

..some questions...

1)What do you mean for no highly skewed cells and too strong non-orthogonality? Can you give an example of high and low values​​?

2)I agree with V. on the fact that the fvScheme and fvSolution could hardly be the same for different problem. First of all the equations are different in multiphase problem (you have an additional term which takes into account the surface forces), the velocity normally are low, no gravity is a good approximation..etc etc.. so i guess that i have to find my "proper" schemes. For example i found that the linearUpwind for the div(rho*phi,U) would not be not a good choise but it would seem better to use Gauss limitedLinearV (i also found some Henry's comments that supports this thing).
At the moment i ran some test and i could find a not too bad solution (is not a perfect circular bubble but at least is fixed at the centre of the domain and does not go away) using leastSquare limited 0.333 for the gradient and the same of V. post for all other quantities, but limited to 0.333. Now i want to check the pressure solution (and the convergence) to see if it is close to the analytical one. So my question is:
How can i print out the residual for each iteration? (From the log i can see the initial and the final residual and total number of iteration for every loop)

3)I'm using OF 1.7, is there the reconCentral schemes? Because i can't find it on the manual.

4)with respect to the comment by markus, also the pointLinear schemes is not there. Can i just add the .H and .C in src/finiteVolume and then recompile the library?

Thanks

andrea
Andrea_85 is offline   Reply With Quote

Old   April 8, 2011, 04:53
Default
  #19
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by Andrea_85 View Post
Hi V., mad and Markus

..some questions...

1)What do you mean for no highly skewed cells and too strong non-orthogonality? Can you give an example of high and low values​​?

2)I agree with V. on the fact that the fvScheme and fvSolution could hardly be the same for different problem. First of all the equations are different in multiphase problem (you have an additional term which takes into account the surface forces), the velocity normally are low, no gravity is a good approximation..etc etc.. so i guess that i have to find my "proper" schemes. For example i found that the linearUpwind for the div(rho*phi,U) would not be not a good choise but it would seem better to use Gauss limitedLinearV (i also found some Henry's comments that supports this thing).
At the moment i ran some test and i could find a not too bad solution (is not a perfect circular bubble but at least is fixed at the centre of the domain and does not go away) using leastSquare limited 0.333 for the gradient and the same of V. post for all other quantities, but limited to 0.333. Now i want to check the pressure solution (and the convergence) to see if it is close to the analytical one. So my question is:
How can i print out the residual for each iteration? (From the log i can see the initial and the final residual and total number of iteration for every loop)

3)I'm using OF 1.7, is there the reconCentral schemes? Because i can't find it on the manual.

4)with respect to the comment by markus, also the pointLinear schemes is not there. Can i just add the .H and .C in src/finiteVolume and then recompile the library?

Thanks

andrea
1) It's difficult to give an exact answer to such a question...In general, concerning OpenFOAM, it is always highly desirable not to have highly skewed cells or strong non-orthogonality detected by the chekMesh utility (the report tells you when it happens and how much are the highly distorted or non-orthogonal cells). To my experience with incompressible High-Re flows, if checkMesh says itěs allright, I've found quite good solutions with max non-orthogonality up to about 60 and max skewness up to 3-4, but of course these could not be taken as general values...

2) If you mean a plot of the residuals, you can simply run the foamLog <log> utility (with <log> name of your log-file) and then plot whatever you need inside the logs folder which is created by the utility itself (I use gnuplot for this)

3) The reconCentral scheme is an additional feature of the -ext release of OpenFOAM (thus it is not part of OF-1.7.0/1). However, thanks to Alberto Passalacqua, you can download the source code and compile it for your OF version from here: Wing Aerodynamics Fluent OF 15 comparison

Hope this helps

V.
vkrastev is offline   Reply With Quote

Old   April 8, 2011, 06:21
Default
  #20
Senior Member
 
Markus Rehm
Join Date: Mar 2009
Location: Erlangen (Germany)
Posts: 176
Rep Power: 8
markusrehm is on a distinguished road
Hi,


Quote:
Originally Posted by Andrea_85 View Post

4)with respect to the comment by markus, also the pointLinear schemes is not there. Can i just add the .H and .C in src/finiteVolume and then recompile the library?
It has been added recently in the 1.7.x-git-repository where my previous link points to.

Markus
markusrehm is offline   Reply With Quote

Reply

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



All times are GMT -4. The time now is 15:57.