[billie]

Hello,

I try to post-process the flow rate through different faceZones. The solver is simpleFoam and the mesh consists of mostly hexaeders, difficult geometric areas are meshed with tetraeders. There is one inlet (turbulent flow profile created with groovyBC) which splits into two separate channels and combines again. This happens three times in total and afterwards there is an outlet (fixed pressure).

geo1.jpggeo2.jpggeo3.jpg

Above pictures show the geometry with the flow direction and the position of the faceZones for evaluating the flow rate.

Due to the flow not approaching symmetrical before the split I expect a different flow rate in the splits. However the sum should always be the flow rate of the inlet. What I get now is correct sums for the splits 3+4 and 5+6 but the sum for the split 1+2 is only about 75% of the total flow rate.

flow_rate.png

From the picture above it is clearly visible that split 1+2 are misbehaving in some way as they should be both in the same range (3e-5) like the other four splits.

I tried postprocessing with swakExpression (swak4foam) and OpenFOAM's fieldFunctionObjects but the results are the same.

So I assume there must be something wrong with the mesh. I deleted parts of the mesh around the faceZones and remeshed them which gave me correct values for other splits but wrong ones which were correct before.

The mesh was created by Hypermesh and exported to OpenFoam format. I had the same problems when exporting to fluent format first and converting the mesh using fluent3DMeshToFoam.

I have no clue how to debug this. Maybe someone can give me a hint.

[billie]

This is definitely a problem with the mesh. I did create a new mesh (only tetraeder) for the same geometry and now the flow rates are reported correct. Is there any way to find out what is wrong with the previous mesh?

[wyldckat]

Greetings Daniel,

Without a snapshot of what the mesh looks like and the values in the relevant cells, I'm only able to suggest two things:

• Do a full checkMesh:
  

  checkMesh -allGeometry -allTopology

  It should tell you if there is anything wrong with the mesh.
• Try using renumberMesh:
  

  renumberMesh -overwrite

  and re-run the case.

Best regards,
Bruno

[billie]

Hi Bruno,

thanks for the response.

Originally Posted by wyldckat

Without a snapshot of what the mesh looks like and the values in the relevant cells, I'm only able to suggest two things:

• Do a full checkMesh:
  

  checkMesh -allGeometry -allTopology

  It should tell you if there is anything wrong with the mesh.

I always run a full checkMesh on my meshes and there is nothing wrong with this one.

Originally Posted by wyldckat

• Try using renumberMesh:
  

  renumberMesh -overwrite

  and re-run the case.

The same goes for renumberMesh, I always run it to reduce the bandwith.

In addition to the first mesh which produces the wrong results and the tetaeder only mesh which reports the flow rate correct I have created a mesh with a prism boundary layers and a tetraeder core. This one also produces wrong results for the flow rate at the faceZones.

The results for Velocity and Pressure look sane for all meshes.

I can report this to Altair. However if I know what is wrong with their meshes it is likely to be fixed earlier. Do you need the complete mesh or just the information about the faceZones.

[wyldckat]

Hi Daniel,

I only need to have a look at the surface mesh on both sides of the "faceZones". If you had values for those faceZones, with the representation "surface with edges", that would make it even if more clearer.

Here's an example of my idea, although it uses surface mesh, not a faceZone: http://www.cfd-online.com/Forums/ope...tml#post451688 - check the attached images on post #6.

Best regards,
Bruno

[billie]

Originally Posted by wyldckat

I only need to have a look at the surface mesh on both sides of the "faceZones". If you had values for those faceZones, with the representation "surface with edges", that would make it even if more clearer.

Here's an example of my idea, although it uses surface mesh, not a faceZone: http://www.cfd-online.com/Forums/ope...tml#post451688 - check the attached images on post #6.

What do you men with both sides of the faceZones and how can I display one side or the other in paraview. Shouldn't the values be the same on both sides. Which values do you need? If you need the values for phi, how can I display them in paraview?

In the meantime I will attach the faceZones colored by U and p.
U_mag.jpgU_Y.jpgp.jpg

[wyldckat]

Hi Daniel,

I had to re-read the whole thread again, to try and figure out what's happening.

Originally Posted by billie

This is definitely a problem with the mesh. I did create a new mesh (only tetraeder) for the same geometry and now the flow rates are reported correct. Is there any way to find out what is wrong with the previous mesh?

This is somewhat odd. Tetrahedral meshes aren't very good for CFD, although sometimes this is the only way to get a simulation going.

Originally Posted by billie

What do you men with both sides of the faceZones and how can I display one side or the other in paraview. Shouldn't the values be the same on both sides.

These values seem to be good enough. I mentioned both sides, because sometimes the mesh is different on each side of a "faceZone", depending on how the meshes on each side were created.

OK, my guesses are as follows:

1. It's possible that the problem is related to not having good y+ values near the walls. In one mesh it might actually be better than on the other mesh.
2. The "faceZones" seem very clean and the results don't look very suspicious on them. Therefore, I suspect that if you check the perpendicular flow profile to those faces along the pipes, it will reveal that there are vortexes being generated near the walls and getting released along the way, leading to the results you are seeing of fluctuating mass flows.
3. The top and bottom pressure levels seem rather suspicious. Their levels are rather different, which the flow rate on both is nearly identical.

Best regards,
Bruno

[billie]

Hi Bruno,

thank you very much for taking the time.

Originally Posted by wyldckat

I had to re-read the whole thread again, to try and figure out what's happening.

This is somewhat odd. Tetrahedral meshes aren't very good for CFD, although sometimes this is the only way to get a simulation going.

I am not worried about the quality of the results itself. The results of all meshes (I have created three now, more about this further down) are okay. Velocities and pressure results are in the same range and look sane. I am worried about that I have an inlet flow rate of 0.00006m3/s and the sum of the flow splits is way lower. Again on the outlet I have the same flow rate as specified on the inlet.

Originally Posted by wyldckat

These values seem to be good enough. I mentioned both sides, because sometimes the mesh is different on each side of a "faceZone", depending on how the meshes on each side were created.

Okay, I understand. My mesh is the same on each side.

Originally Posted by wyldckat

OK, my guesses are as follows:

1. It's possible that the problem is related to not having good y+ values near the walls. In one mesh it might actually be better than on the other mesh.

In addition to the tetraeder only mesh I have created a tetraeder mesh with boundary layer. So the y+ values should be better there but I get the same strange results.

Originally Posted by wyldckat

The "faceZones" seem very clean and the results don't look very suspicious on them. Therefore, I suspect that if you check the perpendicular flow profile to those faces along the pipes, it will reveal that there are vortexes being generated near the walls and getting released along the way, leading to the results you are seeing of fluctuating mass flows.

I am not worried about the fluctuation you see in the picture with the fluxes from my first post. I worry about the sum of split 1+2 which is 0.000046m3/s and not 0.00006m3/s.

Originally Posted by wyldckat

1. The top and bottom pressure levels seem rather suspicious. Their levels are rather different, which the flow rate on both is nearly identical.

The pressure levels are different because the flow goes first through the two bottom splits then through middle ones and at last through the top ones. Pressure is higher first and then decreases. Maybe I should have used a different legend scale for all three split pairs.


I will attach the flow rates for the three meshes I have created.
The sum of the flow rates of split 1+2 should be 0.00006m3s. The same goes for split 3+4 and split 5+6.

First the hexaeder mesh which includes tetraeders in some areas where a mapped mesh is not possible:
hexaeder.png
As you can see the sum for split 1+2 is lower than 0.00006m3/s (approx. 0.0000046m3/s). Split 3+4 and split 5+6 are okay (the same as for the tetraeder mesh below)

Second the tetraeder only mesh:
tetraeder.png
Here the sums are all 0.00006m3/s as it should be.

Third the tetraeder mesh with the boundary layer:
tetraeder_boundary.png
The strange thing is that the sums of split 1+2 are okay (the same as for the tetraeder mesh above) but now split 3+4 and split 5+6 are too low.

So I guess there must be something with the mesh which affects the post-processing of the flow rate.

PS: Regarding the fluctuations you are correct. For the tetraeder mesh with the boundary layer the flow rates are not that fluctuating compared to the other two meshes.

[wyldckat]

Hi Daniel,

Attached are a couple of images that demonstrate how bad tetrahedral cells can be:

• "bad_boundary_layer_p.jpg" - the flow comes from the left to the right and rhoPimpleFoam was used, therefore it's a transient flow. As you can see, the pressure field seems perfectly fine.
• "bad_boundary_layer_U.jpg" - on the other hand, the flow speed "U" field looks terrible near the boundary wall. It looks like a very bad emulation of a rough surface

In this case, the pressure field does look nice enough, but here: http://www.cfd-online.com/Forums/ope...tml#post451688 post #6 - is demonstrated that this is not always like this:



The idea is that tetrahedral cells can be used with success on OpenFOAM, but the mesh has to be perfectly uniform and well shaped, otherwise things will get bad fast enough.

Of course that the same applies to hexahedral cells, as demonstrated on this post: http://www.cfd-online.com/Forums/ope...tml#post446350 post #17 - the image in question is this one:


Don't mind the triangles, because it's a representation artifice used on ParaView. The cells are nicely shaped cubes, but the problem is that the change in the mesh refinement occurs in a very bad place, leading to having simulated flow that goes against the actual flow direction.

In conclusion: you should closely analyse how the flow is behaving throughout all of your mesh, not just in the sections where you are monitoring the mass flow.

Best regards,
Bruno

[billie]

I took a look at the mesh and I still do not think this is related to the quality of the mesh. May I provide the meshes somewhere so you can take a look at them?

[wyldckat]

Originally Posted by billie

I took a look at the mesh and I still do not think this is related to the quality of the mesh. May I provide the meshes somewhere so you can take a look at them?

Quick answer: You can upload it to DropBox or something similar and then send me the link through a private message, if your case is of a sensitive nature.

[wyldckat]

Hi Daniel,

I've received your PM and I've been taking a look at your case V7. Here's what I observed:

1. checkMesh says that everything is perfect. So mesh-wise, there is no problem.
2. From the output of the solver, the residuals seem to indicate that the simulation has converged, although the initial residuals for the "nuTilda" field/equation seem a bit suspiciously higher than I would like them to be... 1e-3 is still a bit high, but everything else is well below 1e-3, so I guess that the result is acceptable.
3. On the other hand, when I start looking at the mesh, it feels that there are some zones on the mesh that are very likely a source of pure trouble. Some examples are shown in the attached images, mostly done by using the "Extract Cells By Region" filter in ParaView:
   • Suspect_01.jpg - This one shows a very suspicious transition between geometries. The zones outlined with the green lines are the transitions I'm referring to. These cells are very stretched and have an inherited curvature that feels like trouble.
   • Suspect_02.jpg - Another inherited curvature. To me, this spells trouble, because if there is by any chance a high transition of flow speed on that curved interface, it's going to be a problem. I forgot to scale the U field for this zone, so there isn't much that can be seem results-wise on this screen-shot.
   • Suspect_03.jpg - For the lack of a better expression: these two zones are very bad! One has overly large tetrahedral cells and the other has very small tetrahedral cells. This is trouble, as implied by the large transitions of flow intensity between each large cell. The problems on the small cells aren't very visible in this image, but it feels like trouble.
   • Suspect_04.jpg - This is a crazy looking image, but I tried to leave it as improbable to decipher, unless one is familiar with the geometry. The problem here is that the cells seem too large, leading the flow speed to have high transitions between cells. In addition, the cells seem somewhat squished... i.e., they are very far from a good cube-shaped cell.
   • Suspect_05.jpg - This does not look like a real flow profile to me. This is related to the zone shown in "Suspect_03.jpg".
     From an artistic point of view, if feels that the vertices or some cells of the mesh on this tetrahedral zone are pebbles on a river bed causing the fluid to flow around them...

If there is any chance you can alleviate these steep transitions of cell size and shape, you should get better results. And if possible, avoid the tetrahedral cells in this area. Convert them to polyhedral, if possible.


As checkMesh implies, this is overall a very nice mesh and seems very much like a very perfect mesh. And the solver is able to respect that and has very nice residuals as a result!
But from the looks of the results themselves, it feels that those very suspicious cells are deforming the fluid flow, which can influence how the curvatures of the flow are shaped and the amount of fluid going through those curved flow ducts. The clear example of this is shown in the image "Suspect_05.jpg".

Notes:

• I used the option "Use VTKPolyhedron" on the ".OpenFOAM" reader in ParaView, so that the cells would be represented as they truly are.
• And I used the cell data representation, so that the real values on the cells were revealed.

Best regards,
Bruno

[wyldckat]

Hi Daniel,

I was curious and took a look at the other meshes you also provided. Here's what I found out:

1. The purely tetrahedral mesh looks great, but suffers from two problems:
   1. Some cells are somewhat larger than the ones surrounding them. This can be bad.
   2. This is pretty much a coarse mesh. There aren't enough cells on the thin zones. You need something like 2 or 3 times more cells on those thin zones.
2. The tetrahedral mesh with boundary layer looks great, but as shown in the attached picture "Zoom_on_cross_section.jpg", the tetrahedral cells look very large and do not seem to be enough to represent the flow on those thin zones.
   1. I used the following OpenFOAM command on this mesh:
      

      polyDualMesh 15 -overwrite

      And resulted in the mesh seem in the image "Zoom_on_cross_section_poly.jpg". It might look very strange, but with any luck, it will behave a lot better than the mesh it originated from. I say this because it basically doubled the number of boundary cells... it converted most of the tetrahedral cells to hexahedral (I have no idea how, but they are not cube-shaped). In total, instead of 1 million cells, it now has 4.5 million .
   2. You might want to try other angles instead of 15, to see if it gives better looking meshes. The idea here is to have better shaped cells than tetrahedral cells, if possible. For more information about polyDualMesh: http://openfoamwiki.net/index.php/PolyDualMesh

Best regards,
Bruno

[billie]

Hi Bruno,

thanks for taking the time. Especially on the weekend I did not expect such a quick reply.

It is surely possible to improve the mesh now even more with the help of your useful remarks. I already tried to convert my mesh to a polyhedra mesh but I got the same results as you, probably because of delaunay violations as mentioned in this post. It seems that polyDualmesh splits all hexaeders into eight Hexaeders and all Tetraeders into four hexaeders. This is why the mesh size increases that much. This also makes the mesh quality worse. Imagine a bad tetraeder split into four heaeders. The angles get even worse.

You took a look an all three meshes and found issues for all of them. So the question is. Why are the fluxes reported correctly with the tetraeder mesh and not with the hybrid (hexaeder/tetraeder) and the mesh with the boundary layer.

Just take a look at fluxes reported by running "gnuplot massfluxsplit.gnuplot" in the directories or take the latest outputs from log.simpleFoam. You can see the sums of split1+2, split3+4 and split5+6 are the same as the specified inflow rate (6e-05) for the tetraeder mesh but split1+2 are to low (4.5e-05) for the hexaeder mesh. For the boundary layer mesh the results are to low for split5+6 (2.9e-5). At the outlet the flux is correct again.
So how can I insert a flux of 6e-05, split the flow where the sum is 4.5e-05 combine it again and have 6e-05 again. If there is such a discrepancy the residuals wouldn't be were they are.

So I guess there is anything wrong with the reported values. As I measure with openfoam and swak4foam and the results are the same I guess there is something wrong with the mesh not related to the quality which only influences the reporting and nothing else.

Additionally, V7 is the seventh variant of those geometries and up to this one I was meshing with the same meshing technique as for the hexaeder/tetraeder mesh you have seen and did not have problems like this. Well I had this some problems for some variants but remeshing with only slightly altered settings fixed it somehow. I was not able to do so for this seventh variant. This is another argument why I do not believe this is a mesh quality issue but something strange in the mesh produced by Hypermesh.

PS: I currently run the Polymesh-Version of the boundary mesh and the results are the same as for the original mesh.

[wyldckat]

Hi Daniel,

It's easier for me to answer on weekends

Originally Posted by billie

You took a look an all three meshes and found issues for all of them. So the question is. Why are the fluxes reported correctly with the tetraeder mesh and not with the hybrid (hexaeder/tetraeder) and the mesh with the boundary layer.

In theory, it's simple: the purely tetrahedral mesh is more uniform than all other meshes, even if some occasional cells are larger. This equates to having a more uniform result, while the others have a flow disturbed by the mesh.

But as I meant to write on the previous post: the tetrahedral mesh with boundary layer is very coarse and the transition to the boundary layer might be too steep.

Originally Posted by billie

PS: I currently run the Polymesh-Version of the boundary mesh and the results are the same as for the original mesh.

Well, like I usually say: polyDualMesh is not the silver bullet. And since the original mesh wasn't perfect CFD-wise, the resulting mesh isn't either. But you might witness some mild improvements in the section cuts I reported about. in the other post.


I believe that the V7 mesh you provided results for, can be improved in the transition zones and then provide the best solution.

Good luck! Best regards,
Bruno

[billie]

I have found the problem, it is definitely related to the mesh but not the quality.

I tried different methods to calculate the flow rate.

OpenFOAM
{
    type            faceSource;
    log             yes;
    valueOutput     false;
    source          faceZone;
    sourceName      inte_1;
    operation       sum;
    fields
    (
        phi
    );
}

Swak4Foam1
{
    type            swakExpression;
    valueType       faceZone;
    outputControl   outputTime;
    outputControlMode   timeStep;
    outputInterval  1;
    zoneName        inte_1;
    expression      "phi*flip()";
    accumulations (
        sum
    );
    verbose         true;
}

Swak4Foam2
{
    type            swakExpression;
    valueType       faceZone;
    outputControl   outputTime;
    outputControlMode   timeStep;
    outputInterval  1;
    zoneName        inte_1;
    expression      "phi";
    accumulations (
        sum
    );
    verbose         true;
}

Swak4Foam3
{
    type            swakExpression;
    valueType       faceZone;
    outputControl   outputTime;
    outputControlMode   timeStep;
    outputInterval  1;
    zoneName        inte_1;
    expression      "mag(U & Sf())";
    accumulations (
        sum
    );
    verbose         true;
    autoInterpolate true;
}

Swak4Foam4
{
    type            swakExpression;
    valueType       faceZone;
    outputControl   outputTime;
    outputControlMode   timeStep;
    outputInterval  1;
    zoneName        inte_1;
    expression      "mag(U.y * area())"; // faceZone lies in the xz-plane
    accumulations (
        sum
    );
    verbose         true;
    autoInterpolate true;
}

This results in the following:
results.png

It looks like there is a problem with face flipping for split 1 and split2. OpenFOAM seems to flip the face automatically. If I remove face flipping in swak4foam (Swak4Foam1 vs. Swak4Foam2) the results are correct (all sums are 6.0e-5).

So there must be anything wrong with the mesh and it is not a bug in OpenFOAM else the results would be wrong for all splits.

Now how to find the bug in the mesh?

[wyldckat]

Hi Daniel,

Nice catch!

"faceZone" normals... it should be the "faceZone" normals that are somehow broken. You can try something that sometimes fixes crazy mesh issues in OpenFOAM:

transformPoints -translate '(1 0 0)'
transformPoints -translate '(-1 0 0)'

In essence, this forces the mesh to get rewritten (translated back and forth), and hopefully it will fix the broken face normals on the "faceZone".

How exactly was that "faceZone" created?

Best regards,
Bruno

[billie]

Originally Posted by wyldckat

"faceZone" normals... it should be the "faceZone" normals that are somehow broken. You can try something that sometimes fixes crazy mesh issues in OpenFOAM:

transformPoints -translate '(1 0 0)'
transformPoints -translate '(-1 0 0)'

In essence, this forces the mesh to get rewritten (translated back and forth), and hopefully it will fix the broken face normals on the "faceZone".

This did not work. I took a look at the SlaveCells required by swak4Foam for flipping the faces. They look like this:
slaveCells.jpg
The SlaveCells marked red are the ones for split1 and split 2. As you can see for the other four splits all cells are at the same side so no flipping is required. The flipMap in constant/polyMesh/faceZones also shows that the faces of split 1 and split 2 have different orientations while the others do not. This is the reason why split 3 to 6 work even if flipping is applied.
Now I believe there is a bug in OpenFOAM and also swak4foam as they both fail to correctly flip the directions.

Originally Posted by wyldckat

How exactly was that "faceZone" created?

Well I made the faceZones in Hypermesh were I simply created Surface-Elements on the relevant faces of the the previously existing volume mesh.

[gschaider]

Originally Posted by billie

This did not work. I took a look at the SlaveCells required by swak4Foam for flipping the faces. They look like this:
Attachment 26273
The SlaveCells marked red are the ones for split1 and split 2. As you can see for the other four splits all cells are at the same side so no flipping is required. The flipMap in constant/polyMesh/faceZones also shows that the faces of split 1 and split 2 have different orientations while the others do not. This is the reason why split 3 to 6 work even if flipping is applied.
Now I believe there is a bug in OpenFOAM and also swak4foam as they both fail to correctly flip the directions.

Well I made the faceZones in Hypermesh were I simply created Surface-Elements on the relevant faces of the the previously existing volume mesh.

The picture you show is a cellSet? cellSets are not preserved during operations that change the cell numbering. Basically there are still the same numbers in the set but they "point" to different cells

[billie]

Originally Posted by gschaider

The picture you show is a cellSet? cellSets are not preserved during operations that change the cell numbering. Basically there are still the same numbers in the set but they "point" to different cells

Yes it is a cell set.
This is why creating the sets is the last operation I run on the decomposed case before actually solving the case.