[chnrdu]

I want to simulate flow in a pipe system which should reflect the pressure pulsation, so I use the solver sonicLiquidFoam.

I have used three types of mesh to simulate it in order to choose a best mesh to be used further: tetrahedra, prism, polyhedra. But the polyhedra, which I am very interested in, cause abnormal pressure:

meshes: 11484
left boundary: pulsate pressure
right boundary: wall
time: 0.003125 s
pressure range: -5.96216e+6, 1.39506e+7


meshes: 44500
boundaries as above, time is the same to above
pressure range: -78, 120


meshes: 51225
boundaries as above, time is the same to above
pressure range: -66, 106

I learned, from a commercial CFD code company, the polyhedral mesh have more advantages: more accuracy, less time cost, fewer meshes, generating mesh automatically. However, the case I simulated is far from my impression. In deed, the time cost is decreased, but the error is too large.

I'd like to ask several questions:
1. why the result computed with polyhedral mesh are far away from the tetra and prism mesh?
2. How to improve the result computed with polyhedral mesh?

[gregorv]

Hello!

The first question is of course the quality of the polyhedral mesh. Did you run checkMesh to see if there are any problems with it? It seems to me that the simulation might be diverging, which can be caused even by only a few bad cells.

Polyhedral meshes may indeed be advantageous in some respects, but getting the polyhedra of adequate shapes is a bit harder than with e.g. tetrahedra.

[chnrdu]

Hi, Gregor.

Thanks for your reply.

I have checked the mesh. the checkMesh result is:

Create polyMesh for time = constant

Time = constant

Mesh stats
points: 61690
edges: 123380
faces: 73175
internal faces: 67911
cells: 11484
boundary patches: 3
point zones: 0
face zones: 0
cell zones: 0

Number of cells of each type:
hexahedra: 31
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 11453

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface
F1 74 146 ok (not multiply connected)
F2 88 174 ok (not multiply connected)
Wall 5102 10204 ok (not multiply connected)

Checking geometry...
Domain bounding box: (0 -0.0159475 -0.0159343) (1 0.0159326 0.0159341)
Boundary openness (5.1346043e-18 -7.9059664e-18 5.7280395e-16) OK.
Max cell openness = 2.2111137e-16 OK.
Max aspect ratio = 7.2639034 OK.
Minimum face area = 5.2550992e-07. Maximum face area = 4.7376251e-05. Face area magnitudes OK.
Min volume = 2.0585726e-09. Max volume = 6.2445933e-07. Total volume = 0.00078484389. Cell volumes OK.
Mesh non-orthogonality Max: 43.57726 average: 12.389229
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 1.3541358 OK.
Min/max edge length = 0.00058204331 0.0040980817 OK.
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : average = 0.99289412 min = 0.85956038
All face flatness OK.

Mesh OK.

Maybe there are some respects to improve. Please point out.

Thank you!

[gregorv]

Hello again,

as far as I can see the mesh itself is perfectly OK.

Are the sizes of the elements for the tetrahedral, prismatic and polyhedral meshes comparable? I still think your solution is simply not converging for whatever reason. It might be something as simple as having too large a timestep, or something more intricate such as various discretisation schemes not being stable enough in the polyhedral formulation.

Unfortunately I have no experience with the actual solver you are using so I can't say much more of use. It is, however, most likely a stability issue, not an accuracy one.

[mkraposhin]

try running
checkMesh with option -cellDeterminant

[hyugakojiro999]

Inflate the walls