[bryant_k]

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:

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:

 createPatch

(with new creatPatchDict file)
But it mentioned that :

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

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

[bryant_k]

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!

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

fluentMeshToFoam

I add one step:

toposet

Then I use command:

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：

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

[bigphil]

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:

fluentMeshToFoam

I add one step:

toposet

Then I use command:

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：

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

[bryant_k]

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:

cat x*>tf.tar.gz

then

tar zxvf tf.tar.gz

(Sorry for the trouble)

And before you run :

icoFoam

set the initial field first:

funkySetFields -time 0

regards!

bryant

[wyldckat]

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:
   

   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:
   

   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

[bryant_k]

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

[wyldckat]

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

[bryant_k]

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.

[wyldckat]

Hi Bryant,

Honestly, this still looks very strange. Perhaps I'm not interpreting the results correctly:

1. Which side if the inlet and which is the outlet?
2. 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