[dlinton]

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

[JNSN]

Hi Daniel,

try

laplacianSchemes
{
      default Gauss linear limited corrected 0.333;
}

snGradSchemes
{ 
      default limited corrected 0.333;
}

Best regards,
Jan

[alexeym]

Hi,

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.

[RodriguezFatz]

Do you get any warnings in the log output?

[dlinton]

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

[JNSN]

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

[alexeym]

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.

[dlinton]

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.

[RodriguezFatz]

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

[JNSN]

Hi Philipp,

from my experience you should NEVER limit grad(p).

Best regards,
Jan

[RodriguezFatz]

I though it's just not p and U at the same time, but why not p?

[JNSN]

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.

[RodriguezFatz]

Ok, then limit U...

[RodriguezFatz]

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?

[dlinton]

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

[RodriguezFatz]

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.

[alexeym]

Hi,

If I start relaxing everything (i.e. just set 0.1 for pressure, velocity, and turbulence parameters), simpleFoam converges:

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).