CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

simpleFoam pipe flow case doesn't converge

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

Like Tree1Likes
  • 1 Post By alexeym

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 8, 2014, 00:31
Default simpleFoam pipe flow case doesn't converge
  #1
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25
me3840 is on a distinguished road
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!

Last edited by me3840; February 8, 2014 at 12:03.
me3840 is offline   Reply With Quote

Old   February 8, 2014, 04:41
Default
  #2
Senior Member
 
Alexey Matveichev
Join Date: Aug 2011
Location: Nancy, France
Posts: 1,938
Rep Power: 39
alexeym has a spectacular aura aboutalexeym has a spectacular aura about
Send a message via Skype™ to 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.
alexeym is offline   Reply With Quote

Old   February 8, 2014, 12:07
Default
  #3
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25
me3840 is on a distinguished road
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!
me3840 is offline   Reply With Quote

Old   February 8, 2014, 12:32
Default
  #4
Senior Member
 
Alexey Matveichev
Join Date: Aug 2011
Location: Nancy, France
Posts: 1,938
Rep Power: 39
alexeym has a spectacular aura aboutalexeym has a spectacular aura about
Send a message via Skype™ to 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

Code:
default         Gauss linear;
to something like

Code:
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

Code:
laplacianSchemes
{
    default         Gauss linear corrected;
}
to

Code:
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

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

Code:
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.
pingat likes this.
alexeym is offline   Reply With Quote

Old   February 8, 2014, 12:54
Default
  #5
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25
me3840 is on a distinguished road
Quote:
Originally Posted by alexeym View Post

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 is offline   Reply With Quote

Old   February 8, 2014, 14:54
Default
  #6
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25
me3840 is on a distinguished road
Also it helps that I realized the inlet velocity was in the wrong direction. Sigh. It converges well now, even without the corrections.
me3840 is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
solving a case on flow through duct hariya03 OpenFOAM Running, Solving & CFD 0 August 10, 2013 17:30
Cannot validate simple pipe flow using simpleFoam inf.vish OpenFOAM Running, Solving & CFD 4 August 6, 2013 08:32
Pipe flow with pressure-inlet lummz FLUENT 3 October 13, 2012 14:29
About Turbulence Intensity (Pipe flow assimilated) gRomK13 Main CFD Forum 1 July 10, 2009 04:11
Terrible Mistake In Fluid Dynamics History Abhi Main CFD Forum 12 July 8, 2002 10:11


All times are GMT -4. The time now is 13:28.