[me3840]

Hello all, I have a simple case of pipe flow to get me introduced to openFOAM. I've only used commercial codes in my life, so this is an interesting experience!

Alright, so I have a pipe r=0.1m and L=0.5m. I built the grid in Salome, it's ~150k cells, tet+prisms. An image of it is attached. It isn't the best, but there aren't any major issues and checkMesh agrees (I think).
http://www.dropbox.com/s/5ex5w0g9saqjqn3/checkMesh.log
http://www.dropbox.com/s/fe1ujn42eathiqm/mesh.png


Here are the residuals from the current solution I have computed. Not really much going on besides tke bottoming out:
http://www.dropbox.com/s/3o10ds4gbo6bvlf/residuals.png

I'm hoping to get just a 5m/s flow of air through this guy. My current fvSchemes and fvSolution are attached. I also attached my U and p files from /0, since I have some concerns with them.
http://www.dropbox.com/s/rxvmt6vvy0317al/p
http://www.dropbox.com/s/fg7kpwfzkv73fq5/U
https://www.dropbox.com/s/fot4xa5rwu8fha7/fvSolution
https://www.dropbox.com/s/wnv8nyuqnjtv2my/fvSchemes

Okay, here are my questions:
1. The syntax for fvSchemes was a little confusing to me, but I'm pretty sure I have selected all 2nd order schemes. Some of the syntax for the upwind ones were giving me errors. Could someone, for example, give me an example for the syntax of div(phi,U) for a 2nd order bounded upwind scheme?
2. In commercial codes I'm pretty used to starting off with 2nd order immediately. Is that too harsh a condition for openFOAM which lacks all the stability algorithms and accelerators and whatnot commercial vendors use? Even for flow in a pipe?
3. Can someone tell me what the point is behind setting a patch type in /constant/polyMesh/boundary when I'm just going to define the BC in the /0 files?
4. I'm not really convinced I'm applying the BCs I want to, I'm hoping I haven't over-specified the system. Let's start with U:
4A. I went with fixedValue everywhere. For commercial codes U is not normally specified explicitly on the outlet boundary, so I'm questioning whether or not I should set it to be the same as my inlet. I'm hoping that setting a fixed (0 0 0) at the wall boundary should be sufficient for a no-slip condition.
4B. For p, I'm pretty sure I set the BC for the inlet as zeroGradient, which is what I'd like for a constant-velocity inlet (I think..). Then I specified a constant-pressure outlet condition at the gauge value. Do these (and the conditions in U) make the problem well-posed?
5. Does anything else strike someone as strange that might be making this case not converge?

Thanks for any and all comments, I'm looking forward to doing more OpenFOAM, it's quite fun!

[alexeym]

Hi,

1. I'd suggest building new mesh with lower non-orthogonality. As it is a simple pipe (i.e. cylinder) you can make fully hexagonal mesh with maximum non-orthogonality around 25.

2. Links to fvSchemes and fvSolution are broken.

3. In constant/polyMesh/boundary file you specify types of BCs (wall, patch etc). And I think it is just additional constrain (for example you can not set wallFunction BC at patch boundary).

4. Your BCs for p and U seems to be OK but you did not show BCs for k and epsilon.

I'd suggest starting with rebuilding a mesh. Or if you'd like to stick with current mesh I'd like to see your fvSchemes and fvSolution.

[me3840]

Thanks for your reply.

I updated the links, they should work now.

1. I wanted to avoid changing topologies, but I'm sure I can make a better mesh with tets. I've heard in places the threshold for non-orthogonality of a good mesh is ~75? Is that true?

4. I didn't include k or epsilon, but they are both fixedValue at the inlet and outlet, and I've calculated their values based on the diameter and turbulent intensity, so I'm not too concerned with them. k has the 'kqRWallFunction' and epsilon has the 'epsilonWallFunction'.

Thanks for your comments, let me know about the two fv* files!

[alexeym]

1. Well, in checkMesh 70 degrees is considered as "severely non-orthogonal" (as it is written in checkMesh.log). And as I said good non-orthogonality for the tube shape is around 30 (here is a blog post about building hexagonal meshes and there is an example of a mesh for cylinder/tube).

2. As you've got this mesh with high non-orthogonality and there is a problem with convergence, you should:
- start with first order schemes (change linear to upwind in divSchemes dictionary)
- use cellLimited or even faceLimited grad schemes, i.e. in fvSchemes you should change

default         Gauss linear;

to something like

default         cellLimited Gauss linear 1.0;

You can find more about it in User manual.
- Also as you've got highly non-orthogonal mesh, you can play with non-orthogonal correction, i.e. again in fvSchemes change

laplacianSchemes
{
    default         Gauss linear corrected;
}

to

laplacianSchemes
{
    default         Gauss linear limited corrected 0.333;
}

the same with snGradSchemes.

3. Again as you've got highly non-orthogonal mesh you should have nonOrthogonalCorrectors in fvSolution above 0, i.e. change

SIMPLE
{
    nNonOrthogonalCorrectors 0;
    residualControl
    {
        p               1e-2;
        U               1e-3;
        "(k|epsilon)"   1e-3;
    }
}

to something like

SIMPLE
{
    nNonOrthogonalCorrectors 3;
    residualControl
    {
        p               1e-2;
        U               1e-3;
        "(k|epsilon)"   1e-3;
    }
}

4. And finally GAMG solver is rather sensitive to its settings. For the beginning you can try to use PCG solver for pressure.

I guess commercial codes will do all this for you behind the scenes.

[me3840]

Originally Posted by alexeym

I guess commercial codes will do all this for you behind the scenes.

Perhaps, but, even as I do there, the best answer is to fix the mesh, which I'll do

I'll look over all the different settings for the orthogonality correctors though, they may be useful in the future!

Thank you!

[me3840]

Also it helps that I realized the inlet velocity was in the wrong direction. Sigh. It converges well now, even without the corrections.