|
[Sponsors] |
October 5, 2015, 18:05 |
Sharp corner with O-grid non-convergence
|
#1 |
New Member
Daniel Linton
Join Date: Mar 2014
Posts: 4
Rep Power: 12 |
Hi Foamers,
Long-time listener, first-time caller. I've been having trouble getting OpenFOAM to converge with simpleFOAM in cases where I have an O-grid wrapped around a sharp, 90 degree corner. I've created a simple test-case to demonstrate this. The geometry is a cube in a planar channel for which I've created two structured meshes in ICEM: the first is a purely orthogonal mesh with refinement near the surfaces of the cube extending all the way to the boundaries, the second has an O-grid around the cube. See the attached image named sharpEdgeMeshComparison. With the orthogonal mesh the convergence is fine and the resulting flow field is good. With the non-orthogonal O-grid case, very high velocities are generated at the cells adjacent to the corner of the cube. The non-orthogonal case will converge using smoothSolver and a straight Gauss-Seidel method as the smoother, however there is still unusually high velocities in the corner cells. Using a GAMG or PCG solver results in non-convergence. Originally I was attempting an unsteady solution using pimpleFOAM, so this is what I've tried so far:
None of these led to a successful solution. I found both of the RANS simulations as well as the potential solution also resulted in very high velocities in the corner cells. I've put exactly the same mesh into two other solvers (FLUENT and a research code) and both have converged smoothly and rapidly with no special treatment. CheckMesh says that everything is OK. Does anyone have any ideas about what might be causing this problem? I hope I'm missing something very straight-forward. I've attached the two versions of the cube test-case albeit without the meshes as they're too large. If you think it would be helpful I can upload the meshes elsewhere and link to them. Kind Regards, Daniel Last edited by dlinton; October 5, 2015 at 21:01. Reason: Forgot to attach case files! |
|
October 6, 2015, 03:05 |
|
#2 |
Senior Member
Jan
Join Date: Jul 2009
Location: Hamburg
Posts: 140
Rep Power: 20 |
Hi Daniel,
try Code:
laplacianSchemes { default Gauss linear limited corrected 0.333; } snGradSchemes { default limited corrected 0.333; } Jan |
|
October 6, 2015, 03:50 |
|
#3 | |
Senior Member
|
Hi,
Quote:
Otherwise you will get bunch of generic advises like limiting non-orthogonal correction, using more viscous gradient schemes (faceLimited/cellLimited variants), etc. |
||
October 6, 2015, 09:39 |
|
#4 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Do you get any warnings in the log output?
__________________
The skeleton ran out of shampoo in the shower. |
|
October 6, 2015, 19:33 |
|
#5 |
New Member
Daniel Linton
Join Date: Mar 2014
Posts: 4
Rep Power: 12 |
Thanks for the replies everyone. Here's a link to the two meshes I've been using: https://www.dropbox.com/sh/3q3wu6qxp...7W0DiiNUa?dl=0.
Jan, thanks for the suggestions, no improvement unfortunately. Rodriguez, I don't get any warnings in the log file or from checkMesh. A suggestion from elsewhere (and from Alexey!) was to try using a face or cell limited gradient scheme (e.g. cellLimited Gauss linear 1). This stabilized the solution a bit but did not lead to convergence. Thanks, Daniel Last edited by dlinton; October 6, 2015 at 19:35. Reason: Credit where credit's due |
|
October 7, 2015, 03:10 |
|
#6 |
Senior Member
Jan
Join Date: Jul 2009
Location: Hamburg
Posts: 140
Rep Power: 20 |
Hi Daniel,
your settings for relaxation Factors are wrong for simpleFoam. Copy the fvSolution from the motorbike tutorial. Then it will work. Best regards, Jan |
|
October 7, 2015, 03:32 |
|
#7 |
Senior Member
|
Hi,
Could you explain why number of cells in non-orthogonal mesh is 3 time lower than in orthogonal mesh? Though visual comparison of the mesh near cube did not reveal any significant difference, since it is k-epsilon who diverges (and divergence starts nowhere near corners, see screenshot at 4th iteration), the problem could be in mesh quality. |
|
October 7, 2015, 03:35 |
|
#8 |
New Member
Daniel Linton
Join Date: Mar 2014
Posts: 4
Rep Power: 12 |
Thanks Jan, you have a sharp eye. For anyone wondering, the problem was that I was missing an "s". Instead of the "fields" subdictionary in the fvSolution file I had a "field" subdictionary so no relaxation factor was applied to the pressure field. It so happens that on a fully orthogonal mesh OpenFOAM can just handle that, but not on a non-orthogonal mesh.
That was frustrating. |
|
October 7, 2015, 03:35 |
|
#9 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Ok, several things:
1) You messed up the under relaxation. Its "fields" and not "field" in fvSolution. In your case, pressure is not under-relaxated which results in very fast divergence of SIMPLE. 2) In my case I needed to limit the pressure gradient scheme "grad(p) faceLimited Gauss linear 1.0;" in order to get a half-decent converge. Anyway, I could not get convergence, residuals remained stable but high. 3) I run yPlusRAS. It says y+ on the cube is average: 46160148. Are you sure your wall mesh is capable of this velocity? @Jan, you were faster
__________________
The skeleton ran out of shampoo in the shower. |
|
October 7, 2015, 03:45 |
|
#10 |
Senior Member
Jan
Join Date: Jul 2009
Location: Hamburg
Posts: 140
Rep Power: 20 |
Hi Philipp,
from my experience you should NEVER limit grad(p). Best regards, Jan |
|
October 7, 2015, 03:48 |
|
#11 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
I though it's just not p and U at the same time, but why not p?
__________________
The skeleton ran out of shampoo in the shower. |
|
October 7, 2015, 03:51 |
|
#12 |
Senior Member
Jan
Join Date: Jul 2009
Location: Hamburg
Posts: 140
Rep Power: 20 |
I should not adorn myself with borrowed plumes, it was an advice from the OpenFOAM support.
And one additional thing (from my experience): in most cases faceLimited is way too divusive to get reasonable results. If you have to use it, it is better trying to get a better mesh quality. |
|
October 7, 2015, 03:53 |
|
#13 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Ok, then limit U...
__________________
The skeleton ran out of shampoo in the shower. |
|
October 7, 2015, 04:00 |
|
#14 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
If I initialize with potentialFoam, I get a converged solution that looks pretty normal. What plane do you use for the picture in the first post?
__________________
The skeleton ran out of shampoo in the shower. |
|
October 7, 2015, 04:34 |
|
#15 |
New Member
Daniel Linton
Join Date: Mar 2014
Posts: 4
Rep Power: 12 |
Hi Philipp,
I've spent so long staring at this file and I couldn't see the mistake. I post it here and two people spot it straight away! The mesh is supposed to be pretty coarse (I'm not actually interested in this cube), but I still get a yPlus of 200 for the cube from yPlusRAS. If I initialize with potentialFoam I don't get a particularly good flow field. The pictures are sliced on the y = 0 plane but they're not from potentialFoam. Cheers, Daniel Last edited by dlinton; October 7, 2015 at 04:37. Reason: Get my facts right. |
|
October 7, 2015, 05:12 |
|
#16 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Maybe I was unclear, sorry.
I initialize the solution with potentialFoam, then I run simpleFoam. The solution looks pretty good after 300 simple iterations. If I don't initialize with potentialFoam and use your init values, I don't get convergence in simple. If you can't manage to reproduce that, just write again.
__________________
The skeleton ran out of shampoo in the shower. |
|
October 7, 2015, 05:54 |
|
#17 |
Senior Member
|
Hi,
If I start relaxing everything (i.e. just set 0.1 for pressure, velocity, and turbulence parameters), simpleFoam converges: Code:
Time = 1204 DILUPBiCG: Solving for Ux, Initial residual = 3.56632251337e-07, Final residual = 3.93417365132e-09, No Iterations 2 DILUPBiCG: Solving for Uy, Initial residual = 7.28635772125e-06, Final residual = 7.25794741745e-07, No Iterations 1 DILUPBiCG: Solving for Uz, Initial residual = 1.03913367289e-06, Final residual = 9.15517461521e-08, No Iterations 1 DICPCG: Solving for p, Initial residual = 9.99430261887e-06, Final residual = 8.71289306071e-07, No Iterations 6 DICPCG: Solving for p, Initial residual = 2.09467760212e-06, Final residual = 2.03791204349e-07, No Iterations 17 DICPCG: Solving for p, Initial residual = 1.00325820883e-06, Final residual = 9.67900054717e-08, No Iterations 14 time step continuity errors : sum local = 1.63018398046e-08, global = 9.08197474318e-10, cumulative = 0.0055360900495 DILUPBiCG: Solving for epsilon, Initial residual = 3.44504920843e-07, Final residual = 2.12140675228e-08, No Iterations 1 DILUPBiCG: Solving for k, Initial residual = 1.00005177154e-06, Final residual = 1.10085675766e-09, No Iterations 2 ExecutionTime = 606.56 s ClockTime = 609 s SIMPLE solution converged in 1204 iterations End |
|
Tags |
convergence, o-grid, orthogonality, sharp corner, simplefoam |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
having problems with performing grid convergence study in SWFS | drdet | FloEFD, FloWorks & FloTHERM | 12 | January 22, 2015 04:44 |
Is convergence criterion (residual value) related with grid size? | rdeepakkumar | FLUENT | 2 | November 9, 2014 01:19 |
Problem with Grid convergence study | dialolema | CFX | 1 | June 14, 2010 18:33 |
Convergence of CFX field in FSI analysis | nasdak | CFX | 2 | June 29, 2009 01:17 |
Relative Error in Grid Convergence | Christopher Haugh | Main CFD Forum | 2 | March 9, 2007 12:42 |