# problem of four patches set to cyclic boundary

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

September 4, 2013, 03:48
problem of four patches set to cyclic boundary
#1
New Member

kob
Join Date: Nov 2011
Posts: 28
Rep Power: 13
Hello everyone
I am simulating a 2D problem.I have attached the case here.The file is a little bit so I move some files out constant/polyMesh, you need put them into ployMesh after you download(Sorry for the trouble).Excluding the front and back boundaries( I set as empty),I need to set the upperBoundary and lowerBoundary to cyclic,so as to leftBoundary and rightBoundary.
The mesh is not hexahedron， you can view them in paraview.
But I failed to set both of them(use createPatch) .I can just only set upperBoundary and lowerBoundary to cyclic or leftBoundary and rightBoundary to cyclic.After I set the boundary as:
Code:
```lowerBoundary
{
type            patch;
nFaces          45;
startFace       6750;
}
upperBoundary
{
type            patch;
nFaces          45;
startFace       6795;
}
frondAndBack
{
type            empty;
nFaces          9120;
startFace       6840;
}
leftAndRight
{
type            cyclic;
nFaces          90;
startFace       15960;
featureCos      0.9;
}```
I run again the command:
Code:
` createPatch`
(with new creatPatchDict file)
But it mentioned that :
Code:
```--> FOAM FATAL ERROR:
face 1 area does not match neighbour 46 by 188.221% -- possible face ordering problem.
patch:upperAndLower my area:0.600393 neighbour area:19.7883 matching tolerance:0.001
Mesh face:15961 vertices:4((-3.00197 -3.14159 0.2) (-3.14159 -3.14159 0.2) (3.14159 -3.14159 0) (-3.00197 -3.14159 0))
Neighbour face:16006 vertices:4((-3.00197 3.14159 0.2) (-3.00197 3.14159 2.77556e-17) (3.14159 -3.14159 0) (-3.14159 -3.14159 0.2))
Other errors also exist, only the largest is reported. Please rerun with cyclic debug flag set for more information.

From function cyclicPolyPatch::calcTransforms()
in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 200.

FOAM exiting```
I also try set them at the same time, but it also wrong.It mentioned that:
Code:
```--> FOAM FATAL ERROR:
face 1 area does not match neighbour 46 by 188.221% -- possible face ordering problem.
patch:upperAndLower my area:0.600393 neighbour area:19.7883 matching tolerance:0.001
Mesh face:15871 vertices:4((-3.00197 -3.14159 0.2) (-3.14159 -3.14159 0.2) (3.14159 -3.14159 0) (-3.00197 -3.14159 0))
Neighbour face:15916 vertices:4((-3.00197 3.14159 0.2) (-3.00197 3.14159 2.77556e-17) (3.14159 -3.14159 0) (-3.14159 -3.14159 0.2))
Other errors also exist, only the largest is reported. Please rerun with cyclic debug flag set for more information.

From function cyclicPolyPatch::calcTransforms()
in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 200.

FOAM exiting```
I am so confused that where is the problem.Thank you for your suggestion!

regards!

bryant_k
Attached Files
 t3.tar.gz (76.5 KB, 3 views) other_files_in_polyMesh.tar.gz (70.4 KB, 3 views)

September 5, 2013, 00:21
#2
New Member

kob
Join Date: Nov 2011
Posts: 28
Rep Power: 13
Hello everyone
I still have not solved my problem.When I try to use the hexahedron grids(I use ICEM to generate meshes),the error disappear.I found a thread :http://www.cfd-online.com/Forums/ope...tml#post392721. Maybe It is similar to my problem.But the problem I met is different with his.
Anyone can give me a suggest?

regards!
Attached Images
 4441.jpg (93.8 KB, 65 views)

September 5, 2013, 04:22
#3
New Member

kob
Join Date: Nov 2011
Posts: 28
Rep Power: 13
hello everyone
I think I have solve my problem.According to this thread:
http://www.cfd-online.com/Forums/ope...tml#post392721

After using command:
Code:
`fluentMeshToFoam`
Code:
`toposet`

Then I use command:
Code:
`createPatch`
Now the error disappear.

But the result using prism meshes is not good compared to the result with hex meshes.Maybe it is the problem about non-orthogonal correction. I don't have experience at this.I have attached the result here and fvScheme here.Or it is not the Scheme problem at all.
The fvScheme：
Code:
```ddtSchemes
{
default         Euler;
}

{
default         Gauss linear;
}

divSchemes
{
default         none;
div(phi,U)      Gauss linear;
}

laplacianSchemes
{
default         Gauss linear limited 0.333;

}

interpolationSchemes
{
default         linear;
interpolate(HbyA) linear;
}

{
default         limited 0.333;
}

fluxRequired
{
default         no;
p               ;
}```
The first one and the second one are the result of prism meshes.(first one with meshes). The last one is the result of hex meshes.

regards!

bryant
Attached Images
 4444.jpg (93.7 KB, 45 views) 44445.jpg (88.6 KB, 40 views) 3333.jpg (88.1 KB, 37 views)

September 5, 2013, 06:28
#4
Super Moderator

Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,063
Rep Power: 33
Quote:
 Originally Posted by bryant_k hello everyone I think I have solve my problem.According to this thread: http://www.cfd-online.com/Forums/ope...tml#post392721 After using command: Code: `fluentMeshToFoam` I add one step: Code: `toposet` Then I use command: Code: `createPatch` Now the error disappear. But the result using prism meshes is not good compared to the result with hex meshes.Maybe it is the problem about non-orthogonal correction. I don't have experience at this.I have attached the result here and fvScheme here.Or it is not the Scheme problem at all. The fvScheme： Code: ```ddtSchemes { default Euler; } gradSchemes { default Gauss linear; grad(p) Gauss linear; } divSchemes { default none; div(phi,U) Gauss linear; } laplacianSchemes { default Gauss linear limited 0.333; } interpolationSchemes { default linear; interpolate(HbyA) linear; } snGradSchemes { default limited 0.333; } fluxRequired { default no; p ; }``` The first one and the second one are the result of prism meshes.(first one with meshes). The last one is the result of hex meshes. Appreciate for your suggestion. regards! bryant
Hi bryant,

To improve the results on the prism mesh, try "leastSquares" for the gradSchemes, and "Gauss skewCorrected linear" for the divScheme.
Also you could try remove the limiters on the laplacianScheme - Gauss linear corrected - and snGradScheme - corrected.

Obviously, try each of these one-by-one to see which has the greater effect on accuracy and stability - I would think the gradScheme will have the largest effect.

Philip

September 9, 2013, 23:45
#5
New Member

kob
Join Date: Nov 2011
Posts: 28
Rep Power: 13
Hello everyone
I have tried many fvSchemes including what Philip suggested for my case, but the result is almost the same.I can get a correct velocity field but a not good pressure field.I tried to refine the meshes,but the result looks the same.
The solver that I use is icoFoam. And I have uploaded the case here.
The case is a little bit so I split it into 3 files.

I thought maybe it is the problem of prism meshes.So I test a cyclinder duct flow with meshes including prism and hex.However the result is good enough.

I am really have no idea of how to improve the simulation.Thanks for you suggestion.

After you down load the 3 files,run command:
Code:
`cat x*>tf.tar.gz`
then
Code:
`tar zxvf tf.tar.gz`
(Sorry for the trouble)

And before you run :
Code:
`icoFoam`
set the initial field first:
Code:
`funkySetFields -time 0`

regards!

bryant
Attached Images
 u.jpg (16.3 KB, 26 views) p.jpg (15.2 KB, 22 views)
Attached Files
 x00.gz (90.0 KB, 10 views) x01.gz (90.0 KB, 6 views) x02.gz (42.9 KB, 7 views)

September 14, 2013, 11:48
#6
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 127
Hi Bryant,

This is a very cool simulation! It's awesome how the flow is able to sustain itself this way!
And the split tarball as several attachments is a neat trick!

Now, as for the problem at hand, the guilty party is... the mesh.
Attached are a few images that demonstrate that the mesh is to blame here:
• "bad_mesh_pressure.jpg" shows the last instance in your simulation (0.34s), showing what the cells look like and what the pressure fields are. Clearly the fault here lies in the mesh.
• "polyDualMesh_15_pressure.jpg" shows what the converted mesh results in. These results are much better, albeit not perfect.
• "polyDualMesh_45_pressure.jpg" is virtually identical to the previous one. I'll explain the difference next.
I got the second mesh by following these steps:
1. Unpacked the tarball.
2. Converted the mesh with the following command:
Code:
`polyDualMesh -overwrite 15`
The "15" is the feature angle for looking at the cells, when generating the dual mesh. I used 45 as well, but the result is identical, because the mesh is 2D. More information: http://openfoamwiki.net/index.php/PolyDualMesh
3. Ran funkySetFields as you indicated:
Code:
`funkySetFields -time 0`
Now, as you can see on the images, this is one of those cases where triangle prisms are bad for CFD. And specially because the cells are not uniform in size and distribution, this distortion of the results occurs even more profoundly.
The polyhedral mesh is better, because it is inherently better at communication flow between cells, given the multitude of faces. Nonetheless, it is not the silver bullet, specially because the original mesh was far from perfect as well. The larger cells have trouble in giving the correct aspect to the result, simply because they are storing more fluid than their neighbour cells.

You can see a similar case here, where this kind of effect is brutal: http://www.cfd-online.com/Forums/ope...tml#post446350 post #17

Best regards,
Bruno
Attached Images
 bad_mesh_pressure.jpg (99.8 KB, 508 views) polyDualMesh_15_pressure.jpg (102.1 KB, 85 views) polyDualMesh_45_pressure.jpg (101.6 KB, 82 views)
__________________

September 16, 2013, 03:54
#7
New Member

kob
Join Date: Nov 2011
Posts: 28
Rep Power: 13
Hello Bruno
Thanks for your explanation.I hope it is the problem of mesh.But I test a cyclinder duct flow with meshes including prism and hex. And the result I think is good.I have attached the files here.

regards!

bryant
Attached Images
 Screenshot-3.png (41.4 KB, 48 views) Screenshot-2.jpg (25.1 KB, 42 views) Screenshot.png (42.2 KB, 45 views) Screenshot-1.png (47.1 KB, 43 views)

 September 17, 2013, 17:18 #8 Retired Super Moderator   Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,969 Blog Entries: 45 Rep Power: 127 Hi Bryant, Well, those latest results seem a bit strange... you should confirm if the flow on the 3rd picture, on the left end of the pipe, if the flow profile looks "physical enough". Because my interpretation from those results is that there is some sort of shock-wave developing near that end of the pipe (3rd picture, left end). Or perhaps the pipe is not long enough for the flow profile to be fully developed? Best regards, Bruno __________________ OpenFOAM: FAQ | Getting started Forum: How to get help, to post code/output and forum guide Read this before sending me PM

September 22, 2013, 03:37
#9
New Member

kob
Join Date: Nov 2011
Posts: 28
Rep Power: 13
Hi Bruno
To make sure the flow is fully developed,I reduced the Renolds number.I have simulated the flow again.The result I think is good also.I have attached the files here.
The second one is velocity,the third and forth picture are pressure.
Attached Images
 mesh.jpg (75.7 KB, 24 views) u.jpg (18.0 KB, 19 views) pl.jpg (13.7 KB, 26 views) p.jpg (15.7 KB, 18 views)

 September 22, 2013, 12:42 #10 Retired Super Moderator   Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,969 Blog Entries: 45 Rep Power: 127 Hi Bryant, Honestly, this still looks very strange. Perhaps I'm not interpreting the results correctly: Which side if the inlet and which is the outlet? These graphs, what's the field being represented and what values does it have? My advice is to also confirm the results by testing with the following: Test using a 2D case, with an identical mesh resolution to the one you've got. Test using a longer pipe. Best regards, Bruno __________________ OpenFOAM: FAQ | Getting started Forum: How to get help, to post code/output and forum guide Read this before sending me PM

 Tags cyclic boundary