|
[Sponsors] |
February 8, 2014, 00:31 |
simpleFoam pipe flow case doesn't converge
|
#1 |
Senior Member
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25 |
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. |
|
February 8, 2014, 04:41 |
|
#2 |
Senior Member
|
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. |
|
February 8, 2014, 12:07 |
|
#3 |
Senior Member
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25 |
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! |
|
February 8, 2014, 12:32 |
|
#4 |
Senior Member
|
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; Code:
default cellLimited Gauss linear 1.0; - 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; } Code:
laplacianSchemes { default Gauss linear limited corrected 0.333; } 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; } } Code:
SIMPLE { nNonOrthogonalCorrectors 3; residualControl { p 1e-2; U 1e-3; "(k|epsilon)" 1e-3; } } I guess commercial codes will do all this for you behind the scenes. |
|
February 8, 2014, 12:54 |
|
#5 | |
Senior Member
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25 |
Quote:
I'll look over all the different settings for the orthogonality correctors though, they may be useful in the future! Thank you! |
||
February 8, 2014, 14:54 |
|
#6 |
Senior Member
Join Date: Nov 2010
Location: USA
Posts: 1,232
Rep Power: 25 |
Also it helps that I realized the inlet velocity was in the wrong direction. Sigh. It converges well now, even without the corrections.
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |