CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM (
-   -   gas flow through a pipe (

megacrout June 16, 2011 13:01

gas flow through a pipe
Hi everyone,

I am trying to simulate the flow of a gas through a pipe due to a pressure difference between inlet and outlet. I first did it using a 5°-element and wedge patches like suggested in the tutorial (user guide). This works great.

As I want to get in the end the entire shape (or at least a quarter of a pipe) and donīt want to compute too many normal vectors for the mirrorMesh function, I tried using other symmetries. But could not get any of them to work.
No matter what I try, I get a physically unjustified slow flow in the center of the pipe (where it should be the fastest). Even though this disappears as the steady state is reached, Iīd like to get the transient situation right too.

Here are the geometries I tried:
- triangle (one corner set equal to another one) with one curved side
- square with one corner at a distance from the opposite corner equal to the two opposite side (i.e. radius) and its two sides curved
- square with a tiny (but not zero) face and a curved one (the opposite one), the two remaining faces being normal to each other

And the patch I tried for the axis or the face close to it (depending on the selected shape):

-wall (patchField slip)

The curved face(s) remained as "wall" and the sides as "symmetryPlane".

I canīt show any code nor pictures of my problem (using 2 computers with no administrator access, internet on one, openFoam on the other one...) so let me know if you need further descriptions.

Thanks for your help.


nsf June 16, 2011 13:45

Hey Tibo,

I once created a python script that outputs a blockMeshDict for a quarter pipe. The mesh that's generated consists of a quarter "o-grid". One centre block and two circumferential blocks.

If you want the entire pipe you can just mirror it twice.

However the python script is commented part in English and part in Swedish. If your interested I can post the script here.

Best Regards


megacrout June 21, 2011 07:13

Hey Nicolas,

Thanks for your answer. This is quite of a late reply, I tried your method and got some other ideas too while working on it...

I get the grid following your idea, even though it is not quite like I would like it (ideally, Iīd like a progressively decreasing cell size on the radial direction, so that the flow can be more accurately described in the vicinity of the pipeīs wall).

The problem now is that I canīt run the simulation, because of the internal faces (between the square and the two triangles). They get automatically defined as "empty" and OpenFOAM does not like it as the problem is not 1D or 2D.

Any suggestion?
Thanks in advance.


nsf June 21, 2011 17:39

1 Attachment(s)
Hey Tibo,

I've (hopefully) attached my python-script. (I had to rename it to .c to upload it). It starts with some editable parts where you define stuff like radius and BLheight. It uses "simpleGrading" in the radial direction.

Have a look at the mesh and the script, should you have any comments or questions I'm happy to reply.

With regards to your mesh, if you post your blockMeshDict I can comment. Though I'm no expert on the subject.


megacrout June 27, 2011 11:20

Ok, I did download it and opened it... but I canīt use it. Can you briefly tell me what I have to do with it please? Compiling it directly using blockMesh does not work. I put it in a "system" folder and tried to run it but OpenFOAM tells me it cannot read the first line. Do I have to split the data in this file into several files? If so, into which ones (names) and where (folders)?

Please excuse such a basic question but Iīm new to OpenFOAM and I did not work much with the C++ language before...

Thanks in advance.

MartinB June 27, 2011 14:08

Hi Tibo,

rename the file to and run the script with:

A new file with name blockMeshDict will appear, which you must copy to the constant/polyMesh directory.


nsf June 28, 2011 15:14

Hi Tibo,

Martin is right. Let us know how it works out for you or if you need further assitance.

If you get the script to work, here's an explination of what the script does:

First there are some variables to set under "User Data", they are

r=38.1/2;            # Radius of the cylinder
height=10;          # Height ( in the axial direction )
BLheight=0.5*r;  # Boundary layer height from walls
lenIB=r-BLheight; # don't change this one
fac=1.22;            # factor that defines where to put
                        #the corner of the inner block
nrCellsAz=20;      # Nr of cells in the azimuthal direction
nrCellsAx=1;      # Nr of cells in the axial direction
nrCellsR=15;      # Nr of cells in the radial direction of the radial blocks
radGrad=0.2;      # EndCellHeight/StarCellHeight < 1, used for grading

Basically what the script does next is to output a blockMeshDict file. Where the position of the vertices is calculated with the above data. It also sets grading in the radial direction.

If you want "a smaller piece of the cake", say half a quarter of a pipe you could change the center block to one or two wedge blocks instead. I haven't tried that, it's just a guess.

Best Regards


megacrout July 7, 2011 06:18

2 Attachment(s)
All right. First of all, thanks a lot to all of you. I really appreciate the fact you take the time to explain to me how the basic stuff goes.

Secondly, this mesh is great. Exactly what I was trying to do. Simple grading in the center and refined mesh on the pipeīs surface to properly describe the laminar flow.

However, Iīm afraid this does not work. I tried with symSouth and symNorth (the radial sidesī patches) defined with a patch type "patch" as in Nicolasī file (patch field type "zeroGradient") as well as with a patch type "symmetryPlane" (patch field type "symmetryPlane") and got in both cases a problem similar to the one I describe at the beginning of this thread. Instead of the flow being slowed down at the axis, as in my initial problem, it is now slowed down at the top left corner of the central "square".

If what I did is the same as what you did, Nicolas, you might have not seen the mistake because the top left corner of your square is close enough to the surface. However, you can notice the solution is not quite satisfying while looking at the transient states, e.g. the first time step (s. appendix).
This is however even easier to notice with a smaller inner square, as I tried by slightly modifying your code (s. second appendix, also first time step).

Two questions:
1) May I have coded something improperly (did you also get these result(s), Nicolas?) ? If so, what file(s) should I look at?
2) If it seems to have been properly run, what could be the explanation to these "wrong" results and how can I solve it? Use a different solver? A different mesh?

Thanks for your time.

nsf July 7, 2011 15:47

1 Attachment(s)
I'm glad you like the mesh! Actually, until today I actually never ran the case. But today I did try and did get an ok solution. Meaning I cant observe the same behavior as you did, see attachment. However I didn't put any effort in to replicating your results.

To answer your questions

1.) Well I can't spot anything but then you haven't showed everything you've done so I can't exclude it. I presume you have chosen reasonable values with regards to axial length and number of cells.

I'm not sure of what went wrong. Here's my guess. The error is close to the corner of the central block since that's the place where you have high skewness. If you compare the skewness (with checkMesh) of the two meshes I think you will find that the skewness of the second mesh is worse ( I can never recall but I think in OF good skewness is close to zero).

One remedy is to work with the mesh and reduce skewness. Try setting arcs on the edges of the center block. Play around with BLheight parameter in the script. However it's a circular pipe so you can't get rid of all skewness.

Another remedy is as you suggested to change the solver (which did you use?). Did you try pimpleFoam? Also look at the settings in fvSolution and fvSchemes. My first try would be to increase nOuterCorrectors and/or nNonOrthogonalCorrectors. Try it with the second (really bad) mesh and hope for improvement.

Good luck and let me know how it goes!


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