# Sharp corner with O-grid non-convergence

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

 LinkBack Thread Tools Search this Thread Display Modes
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: 11
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:
• Adding outer loops to the solution algorithm and dropping the under-relaxation factors a lot (as far as 0.01 for the pressure)
• Adding up to 20 non-orthogonal correctors
• Reducing the CFL number (as low as 0.05)
• Ramping the inlet velocity slowly
• Reverting to first-order schemes for the divergence operator
• Starting from an approximate, divergence free solution generated from a potential flow solver
• Attempting a steady-state RANS solution using k-epsilon and Spalart-Allmaras

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
Attached Images
 sharpEdgeMeshComparison.png (127.5 KB, 100 views)
Attached Files
 sharpCornerTestSansMesh.tar.gz (14.4 KB, 11 views)

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: 125 Rep Power: 19 Hi Daniel, try Code: ```laplacianSchemes { default Gauss linear limited corrected 0.333; } snGradSchemes { default limited corrected 0.333; }``` Best regards, Jan

October 6, 2015, 03:50
#3
Senior Member

Alexey Matveichev
Join Date: Aug 2011
Location: Nancy, France
Posts: 1,930
Rep Power: 38
Hi,

Quote:
 Originally Posted by dlinton 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.
It would, since the problem appears on certain mesh at least post a link to O-type mesh file.

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: 26 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: 11 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: 125 Rep Power: 19 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

Alexey Matveichev
Join Date: Aug 2011
Location: Nancy, France
Posts: 1,930
Rep Power: 38
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.
Attached Images
 diverning-epsilon.png (16.2 KB, 38 views)

 October 7, 2015, 03:35 #8 New Member   Daniel Linton Join Date: Mar 2014 Posts: 4 Rep Power: 11 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: 26 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: 125 Rep Power: 19 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: 26 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: 125 Rep Power: 19 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: 26 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: 26 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: 11 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: 26 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

Alexey Matveichev
Join Date: Aug 2011
Location: Nancy, France
Posts: 1,930
Rep Power: 38
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```
(well, around iteration 800 I have switched to standard values of relaxation factors for simpleFoam (p - 0.3, U - 0.7, k/epsilon - 0.5), guess, if I keep 0.1, convergence would take longer).
Attached Images
 Ux.png (43.1 KB, 42 views)
Attached Files
 nonOrtho.tar.gz (2.7 KB, 5 views)

 Tags convergence, o-grid, orthogonality, sharp corner, simplefoam

 Thread Tools Search this Thread Search this Thread: Advanced Search Display Modes Linear Mode

 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 OffTrackbacks are Off Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post drdet FloEFD, FloWorks & FloTHERM 12 January 22, 2015 04:44 rdeepakkumar FLUENT 2 November 9, 2014 01:19 dialolema CFX 1 June 14, 2010 18:33 nasdak CFX 2 June 29, 2009 01:17 Christopher Haugh Main CFD Forum 2 March 9, 2007 12:42

All times are GMT -4. The time now is 00:11.

 Contact Us - CFD Online - Privacy Statement - Top