|
|
snappyHexMesh_holes.png (98,921 bytes) |
|
|
snappyHexMesh is warning you that after castellation the normal at a point points through the connected boundary faces. This can happen in complicated geometries where the outside of the castellated mesh is non-manifold or if the mesh has 'bled' into the geometry. You can run snappyHexMesh in stages and check the result of the castellation phase to see where they're originating from. |
|
|
I've done it step by step, but log of snappyHexMesh doesn't has any warning/errors for the castellated stage. So the problem is in snapping... |
|
|
You could check the castellated mesh visually (e.g. using paraFoam). Check for non-manifold connectivity on the outside. |
|
|
snappy_castellated.png (65,225 bytes) |
|
|
snappy_castellated1.png (77,020 bytes) |
|
|
Visually it's OK and have no errors. (look on the pictures above) |
|
|
I'm not the only one with this problem. For example: http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/149358-snappyhexmesh-displacement-mesh-point-points-through-surrounding-patch-faces.html |
|
|
Did you follow the steps as in that discussion? I.e. your mesh is as good as your quality parameters allow so start off with low quality constraints. 2) If you run checkMesh -allTopology -allGeometry on your castellated mesh it will also warn you (running serial only) for non-manifold patches. |
|
|
The output of checkMesh: Checking geometry... Overall domain bounding box (-17 -35.5 -28.75) (18 44.375 10.9375) Mesh (non-empty, non-wedge) directions (1 1 1) Mesh (non-empty) directions (1 1 1) Boundary openness (-7.90676e-18 -1.50526e-17 -1.91615e-17) OK. Max cell openness = 2.96059e-16 OK. Max aspect ratio = 2.25 OK. Minimum face area = 0.078125. Maximum face area = 2.8125. Face area magnitudes OK. Min volume = 0.0439453. Max volume = 2.8125. Total volume = 3686.75. Cell volumes OK. Mesh non-orthogonality Max: 40.6286 average: 12.2505 Non-orthogonality check OK. Face pyramids OK. Max skewness = 1 OK. Coupled point location match (average 0) OK. Face tets OK. Min/max edge length = 0.25 2.25 OK. <<Writing 26 near (closer than 9.58129e-05 apart) points to set nearPoints All angles in faces OK. Face flatness (1 = flat, 0 = butterfly) : min = 1 average = 1 All face flatness OK. Cell determinant (wellposedness) : minimum: 0.720924 average: 12.477 Cell determinant check OK. ***Concave cells (using face planes) found, number of cells: 2359 <<Writing 2359 concave cells to set concaveCells Face interpolation weight : minimum: 0.333333 average: 0.467477 Face interpolation weight check OK. Face volume ratio : minimum: 0.125 average: 0.829253 Face volume ratio check OK. Failed 1 mesh checks. |
|
|
Greetings to all! @Svensen: Since there isn't a test case I can "play" with, I had to rely on a "Sherlock Holmes moment" and examine the provided images in deep detail. This to say that I'm doing a calculated guess, which can only be verified with the case in question or with a small sample of the case being used. At least a biopsy of the geometry would come in handy!? ;) My deduction based on the images and on the "checkMesh" output is that the base mesh that was possibly created with blockMesh (for the lack of a better expression) is bad for this geometry. The problem is that instead of having cells that look like "near perfect cubes", the castellated mesh shows a mesh with cells that resemble "elongated bricks". This wouldn't be much of a problem if the geometry was similar enough to said brick-like cells, but in this case, you're witnessing the incorrect collapse of one or both corners of some cells near the walls (although it could also happen with cube-like cells). And it's these cell corners that are possibly being reported by the checkMesh line that ends in "nearPoints". At least this is what I can figure out without a test case. The other deduction is somewhat simple: OpenFOAM 2.3.0 is being used. And if the mesh was generated in parallel, I strongly suggest you upgrade to 2.3.1, since this does somewhat look like a bug that might have already been fixed. Which again, could have been easily confirmed with a test case ;) Best regards, Bruno |
|
|
The size of test case is bigger then the 2 Mb, so I've uploaded it to the cloud storage: https://yadi.sk/d/vw89bWKbfYZ4B It contains another aneurysm geometry but have the same problems like in the above pictures. For previous cases I've tried to use cubic cells in background mesh, but it seems that it isn't help. After snap process all of my meshes contains some bad cells. The mesh was generated in serial. |
|
|
Is it a bug in snappyHexMesh or I simply have done something wrong with snappyHexMeshDict ? |
|
|
Hi, here is the run with 2.3.x (git version). I only changed blockMeshDict (as suggested by Bruno): blocks ( hex (0 1 2 3 4 5 6 7) (45 25 20) simpleGrading (1 1 1) ); No errors/warnings are reported by checkMesh: /*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.3.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ Build : 2.3.x-1449a6736452 Exec : checkMesh Date : Mar 28 2015 Time : 13:19:44 Host : "....." PID : 3552 Case : /..../testCase_snap nProcs : 1 sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). fileModificationChecking : Monitoring run-time modified files using timeStampMaster allowSystemOperations : Allowing user-supplied system call operations // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create polyMesh for time = 0 Time = 0 Mesh stats points: 178685 faces: 471416 internal faces: 431853 cells: 149861 faces per cell: 6.02738 boundary patches: 2 point zones: 0 face zones: 0 cell zones: 0 Overall number of cells of each type: hexahedra: 121108 prisms: 10412 wedges: 0 pyramids: 0 tet wedges: 313 tetrahedra: 7 polyhedra: 18021 Breakdown of polyhedra by number of faces: faces number of cells 4 7138 5 3185 6 2108 9 2016 12 2056 15 1328 18 190 Checking topology... Boundary definition OK. Cell to face addressing OK. Point usage OK. Upper triangular ordering OK. Face vertices OK. Number of regions: 1 (OK). Checking patch topology for multiply connected surfaces... Patch Faces Points Surface topology vessel_cube 0 0 ok (empty) flange 39563 46067 ok (closed singly connected) Checking geometry... Overall domain bounding box (-17.6752 -35.0042 -28.8464) (18.0707 43.999 11.1233) Mesh (non-empty, non-wedge) directions (1 1 1) Mesh (non-empty) directions (1 1 1) Boundary openness (-4.68144e-17 -1.06821e-16 -8.87313e-18) OK. Max cell openness = 4.30541e-16 OK. Max aspect ratio = 10.4635 OK. Minimum face area = 0.00176546. Maximum face area = 1.13748. Face area magnitudes OK. Min volume = 0.000966931. Max volume = 1.14059. Total volume = 3714.38. Cell volumes OK. Mesh non-orthogonality Max: 64.9963 average: 12.4419 Non-orthogonality check OK. Face pyramids OK. Max skewness = 3.1243 OK. Coupled point location match (average 0) OK. Mesh OK. End However the "holes" are still visible. See attached picture. |
|
2015-03-28 12:43
|
snappy_test.png (174,067 bytes) |
|
2015-03-28 12:56
|
snappy_test_hole.png (11,484 bytes) |
|
|
Do you use Salome to export stl file? |
|
|
The stl surface was obtained from the clinical data, then I've closed the inlet and outlet holes with netfabb. Netfabb says OK during the surface check. |
|
|
internal_mesh_polyhedron_foam_vs_OpenFOAM.png (154,863 bytes) |
|
|
surface_mesh_polyhedron_foam_vs_OpenFOAM.png (152,338 bytes) |
|
|
I've attached are 2 images: - internal_mesh_polyhedron_foam_vs_OpenFOAM.png - surface_mesh_polyhedron_foam_vs_OpenFOAM.png As the names state, they are representations of the internal and surface meshes, both rendered in their natural polyhedron representation. The data is loaded with the ".foam" (uses the built-in reader in ParaView) and the ".OpenFOAM" (uses the official reader from OpenFOAM for ParaView) file extensions. In case you haven't deduced yet from these images, the holes you're seeing are actually misrepresentations of the cells for the internal mesh, i.e. they technically don't exist as holes. This is due to a glitch in the ".OpenFOAM" reader which is incorrectly populating some cell representations, for both decomposed and polyhedron representations. This has been seen in the past a few times, but there hasn't been much effort to try and fix this, since this somewhat rarely occurs. But in the provided model, this is a lot more frequent. I'm going to see if I can extract a "biopsy" of the mesh that has these cells, so that it's easier to diagnose where is the glitch in the source code for the ".OpenFOAM" reader. |
|
|
I have done also a test exporting the mesh to fluent. I have done the same cut as in Of and I could see no "holes". In paraFoam if one selects the walls instead of interior, again no "holes" are to be seen. |
|
|
before_fix.png (194,140 bytes) |
|
|
after_fix.png (191,908 bytes) |
|
|
|
|
|
So, as I understand the problem of holes in the mesh is caused by some error in OpenFOAM reader plug-in which is distributed with OpenFOAM. I load my snapped mesh with paraview and there are no holes in the internal mesh. BUT, after that I've tried to make a complete snappyHexMesh process (castellated+snap+addLayers) and after addLayers stage some holes was created (you can see them on the picture that I've attached). The holes are still exist when I open the mesh both in paraFoam and paraview. It seems that there is another bug... |
|
|
|
|
|
snappy_after_addLayers.png (139,332 bytes) |
|
|
This was a nice effort, if I may say so myself! The bug fix provided in the attachment "vtkPV4FoamMeshVolume.C_patch" also fixes the rendering issue that was reported back in Issue #295 http://www.openfoam.org/mantisbt/view.php?id=295 - in the last image "normal_resolution_new_missing_cell.png". The images "before_fix.png" and "after_fix.png" demonstrate how the provided bug fix resolves this issue. The attached case "biopsy.tar.gz" has a very small subset mesh that has one of the problem cells that looks like it has a hole. There is also another cell there that seems problematic... I'll see if I can figure out what's wrong with it. Edit: It's pretty complicated cell formatting issue... I can't figure it out without spending several hours analysing this :( |
|
|
wyldckat, can you apply your patch on OpenFOAM-2.3.x version in git repository ? What do you think about the holes after addLayers stage ? |
|
|
@Svensen: I don't have permissions to apply to the 2.3.x git repository. But you can easily apply it in your own local repository with the following commands: git checkout -b bug1633 patch -p1 < vtkPV4FoamMeshVolume.C_patch git commit -am "applied patch for vtkPV4FoamMeshVolume.C" When the 2.3.x repository is finally updated, you can do: git checkout master git pull The holes you're seeing after the addLayers stage should be the exact same problems I pointed out, namely that the problem is a rendering issue with the ".OpenFOAM" reader. If in the "mesh parts" entry you unselect "internalMesh" and select "flange", you'll no longer see the holes. |
|
|
Yes, you are right if I select "flange" no holes exists. But the following problem occurs... I've already tried to do some small computation on this mesh (when it have some "rendered" holes). The problem is when you try to post-process your solution, paraview incorrectly apply the velocity field on mesh. For example, in this model the maximum velocity is about 2 m/s. But paraview shows on some "bad" cells the value of velocity is about 8 m/s. It is of course incorrect. That's why you cannot post-process the resulting velocity field in a right way... So another bug in addLayers stage exists... |
|
|
About applying patch to the git version of OF-2.3.x. Can we somehow ask henry about this ? Maybe he can apply a patch |
|
|
@Svensen: Once again, I'll need a test case to ascertain what's happening... |
|
|
You are asking about computational results for velocity field ? Am I right ? |
|
|
> You are asking about computational results for velocity field ? Am I right ? Yes, I was requesting the test case so that I can see the values for myself, because I suspect there is more to it than what you're thinking there is ;) As for applying the proposed patch on 2.3.x, I think Henry or Mattijs will have to first test this themselves, to double-check if this fixes the issue or not. |
|
|
I will test the patch and push the change if all is well. |
|
|
wyldckat, I have to go away for sometime, I think during a hour I will post a test case with a computational results. Is it OK ? |
|
|
@Svensen: No problem. I'll have a look into it tomorrow. |
|
|
addLayers_wrong_velocity_range.png (51,912 bytes) |
|
|
addLayers_wrong_velocity_range_threshold.png (208,237 bytes) |
|
|
The test case is here: https://yadi.sk/d/jq45O385farc9 Also I've uploaded sample screenshots. |
|
|
Threshold_Umag.png (151,039 bytes) |
|
|
holes.png (36,601 bytes) |
|
|
@Svensen: The attached file "Threshold_Umag.png" demonstrates that you should apply the "Threshold" filter to the "Cell Data", not to the "Point Data". Therefore, that specific issue isn't a bug. @Henry and Mattijs: I finally managed to see what they meant by "holes in the mesh", it's now shown clearly in the attached image "holes.png". These appear when using the decomposed polyhedron representation. I'll do another "biopsy" and see if I can figure it out. Edit: These specific holes appeared in the latest case, namely after adding layers... |
|
|
Are these real "holes" in the mesh or an artifact of the visualization, either a problem with data conversion to ParaView or with the way ParaView handles polys? |
|
|
@Henry: The latest holes are an artifact of the polyhedron decomposition. According to what I'm seeing right now, at least one of the cells has a face on the outside that is convex, which has resulted in having 2 identically overlapping (and very squished) pyramid cells that make up the decomposition of that face. I have yet to figure out if the only difference is in the order of the points. I'll attach the test case package "biopsy2.tar.gz" in a few minutes. |
|
|
|
|
|
What does it look like if you use the VTKPolyhedron option? I guess if you run checkMesh with -allGeometry -allTopology it tells you there is a problem with negative volume pyramids. |
|
|
If we use the VTKPolyhedron option, it's properly represented. When we use the full checkMesh on the biopsy2 case, these are the major issues: <<Writing 2 cells with zero or one non-boundary face to set oneInternalFaceCells <<Writing 2 cells with two non-boundary faces to set twoInternalFacesCells ***Number of edges not aligned with or perpendicular to non-empty directions: 37 <<Writing 20 points on non-aligned edges to set nonAlignedEdges ***Cells with small determinant (< 0.001) found, number of cells: 5 <<Writing 5 under-determined cells to set underdeterminedCells The cell that doesn't represent properly in this small test case is part of "underdeterminedCells". In fact, if I visually decompose this cell, it results in one cell on the surface that has pretty much no thickness and another one that is a reasonable tetrahedra. If we apply in ParaView the filter "Clean Cells to Grid", it fixes part of the problem, but also removes some additional cells that didn't seem to be a problem in the first place. -------------------------- Conclusions: 1- The first proposed fix "vtkPV4FoamMeshVolume.C_patch" is still good to be applied, since it solves the problem with misrepresented tetWedges (test case "biopsy.tar.gz"). Said fix should be applicable to the PV3 reader as well. 2- If holes start appearing on the mesh's surface, then either: use the filter "Clean Cells to Grid"; or also choose to represent the surface mesh; or use the VTKPolyhedron option. Because such a representation is a symptom of some very bad cells. |
|
|
high_velocity_cell.png (216,281 bytes) |
|
|
"such a representation is a symptom of some very bad cells", but does snappyHexMesh have to control the quality of the generated mesh with meshQualityDict ? During mesh generation it was no errors... About the threshold filter, yes it's working well but if you look at screenshot above it's quite strange that there is only ONE cell with high velocity value in the region. It looks some kind of non-realistic. |
|
|
high_speed_cell.png (19,421 bytes) |
|
|
@Svensen: The attached image file "high_speed_cell.png" tries to demonstrate the cell that has the very high speed you pointed out in the image "high_velocity_cell.png". As you might be able to see, the cell is a very complex polyhedral cell, which is very squished and is a very concave in a few directions (I was confused before as to what "convex" actually was :( ). This resulted in "potentialFoam" to have several numerical issues and making this cell have a flow with high velocity. As for quality control... well, "snappyHexMesh" followed the definitions you gave it in the dictionary file "meshQualityDict". I would suspect that this option: minTetQuality 1e-15; would be one of the responsible parameters for these weird cells. "minVolCollapseRatio" might also be helpful in eliminating such cells. You'll have to try this out yourself. |
|
|
Thanks Bruno for analysing and fixing this. Resolved by commit a79b45c6115abf706d6d3c0d8fac36e8ffade1c6 |
- Anonymous
