View Issue Details

IDProjectCategoryView StatusLast Update
0002099OpenFOAM[All Projects] Bugpublic2016-08-26 00:58
ReporterSvensenAssigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Version 
Fixed in Version 
Summary0002099: snap stage generates internal triangles
DescriptionDuring the snap stage the snappyHexMesh generates illegal internal triangles (see attached images for comparison of original STL geometry and mesh generated by snappyHexMesh). The STL was checked with surfaceCheck, the log is the following:

surfaceCheck -checkSelfIntersection aneurysm.stl

Reading surface from "aneurysm.stl" ...

Statistics:
Triangles : 7462
Vertices : 3733
Bounding Box : (-8.17053 -9.95681 -3.16317) (9.29674 5.487 18.3778)

Region Size
------ ----
patch0 7462


Surface has no illegal triangles.

Triangle quality (equilateral=1, collapsed=0):
    0 .. 0.05 : 0
    0.05 .. 0.1 : 0
    0.1 .. 0.15 : 0
    0.15 .. 0.2 : 0
    0.2 .. 0.25 : 0
    0.25 .. 0.3 : 0
    0.3 .. 0.35 : 0
    0.35 .. 0.4 : 0
    0.4 .. 0.45 : 0.000402037
    0.45 .. 0.5 : 0.000268025
    0.5 .. 0.55 : 0.0010721
    0.55 .. 0.6 : 0.00160815
    0.6 .. 0.65 : 0.00254623
    0.65 .. 0.7 : 0.0032163
    0.7 .. 0.75 : 0.00402037
    0.75 .. 0.8 : 0.00522648
    0.8 .. 0.85 : 0.0087108
    0.85 .. 0.9 : 0.0305548
    0.9 .. 0.95 : 0.118467
    0.95 .. 1 : 0.823908

    min 0.409765 for triangle 7461
    max 0.999999 for triangle 6093

Edges:
    min 0.116441 for edge 2482 points (6.99224 0.323031 -1.78307)(6.89283 0.373643 -1.81644)
    max 0.771082 for edge 5440 points (-6.57135 -9.32061 1.086)(-6.66217 -9.95464 1.51533)

Checking for points less than 1e-6 of bounding box ((17.4673 15.4438 21.541) metre) apart.
Found 0 nearby points.

Surface is closed. All edges connected to two faces.

Number of unconnected parts : 1

Number of zones (connected area with consistent normal) : 1

Checking self-intersection.
Surface is not self-intersecting

End

There is no obvious error in STL surface.

In the same time, for mesh the wall patch is OK, but first layer of internal mesh include these illegal triangles.

Can someone fix this ?

P.S. The project files are available here: https://yadi.sk/d/AvRBv_eMryyhe
TagsNo tags attached.

Relationships

related to 0002213 resolvedhenry "vtkTopo.C" in foamToVTK library is missing the same fix as provided in #1633 
related to 0002219 closedwyldckat Proposition for deprecating the representation of tetWedge with a collapsed VTK_WEDGE when exporting to VTK 

Activities

Svensen

2016-05-25 15:50

reporter  

Svensen

2016-05-25 15:51

reporter  

wyldckat

2016-05-26 02:56

updater   ~0006324

Many thanks for providing this case! This and your report #1633 is giving us some very nice debugging material for some render/exporting issues in ParaView and foamToVTK!

I've done some preliminary analysis on this and the problem is how the cells are being constructed and delivered to ParaView.
Fortunately this isn't a bug that would imply a regression for the fixes implemented for #1633, as shown in the attached images "comparison_OF30x.png" and "comparison_OF22x.jpg", where it's clear this is a new bug.

Another fortunate detail is that for the time being, you can use the built-in reader that ParaView, which doesn't have this specific problem, which you can do by running:

  paraFoam -builtin


As for the bug itself, it seems to occur in both foamToVTK and OpenFOAM's "PV*Readers" plug-ins.
I'll try to take a better look into this as soon as I can, but it will likely take me a few/several days until I'm able to look into it. If anyone else wants to look into this, please do feel free to pick it up before I do ;)

wyldckat

2016-05-26 02:57

updater  

comparison_OF22x.jpg (538,305 bytes)

wyldckat

2016-05-26 02:57

updater  

comparison_OF30x.png (104,905 bytes)
comparison_OF30x.png (104,905 bytes)

Svensen

2016-06-05 09:39

reporter   ~0006372

wyldckat, do you have any success ?

henry

2016-06-05 14:27

manager   ~0006373

I am looking at your case in OpenFOAM-dev with ParaView-5.0.1 and I don't see any issues, at least it looks fine with the standard OpenFOAM handling of polyhedral cells. There are some artifacts with the vtkPolyhedron option but these are minor and probably due to the limitation of the VTK polyhedral cell handling and hence I see the same with the "builtin" reader which also uses the VTK polyhedral cell functionality.

checkMesh indicates the mesh is correct so I don't see any problem.

Could you try with OpenFOAM-dev and ParaView-5.0.1 and if you still see some issues could you provide details about the view in which you see them?

Svensen

2016-06-05 17:55

reporter   ~0006374

Yes, I know that checkMesh reports that there are no problems, but if you try "checkMesh -allGeometry -allTopology" it will report a lot of bad cells...

henry

2016-06-05 18:15

manager   ~0006375

If you have a problem with the bad cells you can change the snappyHexMesh settings to improve them at the expense of poorer surface and edge conformance.

Have you tried viewing the mesh in OpenFOAM-dev with ParaView-5.0.1?

wyldckat

2016-06-06 15:15

updater   ~0006384

Sorry to both of you, but I haven't been able to look into this in more detail.
And I'm expecting the problem is still present in OpenFOAM-dev+ParaView 5.0.1, although I haven't confirmed this yet.

I forgot to specify on the first comment the following details:

 1- The cells with the rendering problems in ParaView are not in the list of cells and/or faces pointed out by "checkMesh -allTopology -allGeometry".

 2- And if I remember correctly, the cells with problems are the ones that have 7 vertexes. The issue seemed to be due to 2 or 3 points being swapped around.


I'm expecting the issue is in the file "applications/utilities/postProcessing/graphics/PVReaders/PVFoamReader/vtkPVFoam/vtkPVFoamMeshVolume.C", as well as somewhere in the "foamToVTK" library as well, when using "-poly".

henry

2016-06-06 15:45

manager   ~0006387

I see more surface artifacts with the ParaView "builtin" reader than with the OpenFOAM reader. Are you sure the problem is in OpenFOAM code rather than VTK code? If so is someone going to look into fixing the "builtin" reader also?

wyldckat

2016-06-06 16:27

updater   ~0006390

> Are you sure the problem is in OpenFOAM code rather than VTK code?

If I remember correctly, the artifacts in the built-in reader were not coincident nor near the ones provided by OpenFOAM's export, which is why I concluded that the issue with the 7 vertex cells was on OpenFOAM's side.


> If so is someone going to look into fixing the "builtin" reader also?

Possibly, although some of those fixes might already be in the project that has provided many of the features available in the built-in reader: https://github.com/7islands/vtkPOFFReader - still have to check that as well. Right now that project is also in need of contributors.


But it does look like proper validation work is needed for polyhedral cells, for both VTK/ParaView and OpenFOAM's VTK export capabilities. I'm not sure if VTK has this validation in its test array, although it should have it.

Svensen

2016-06-08 17:57

reporter   ~0006410

Sorry, it took some time to me to compile OpenFOAM-dev from source.

According to the question from henry: yes, I still see the illegal triangles in the mesh using OpenFOAM-dev and ParaView 5.0.1.
You can look inside inlet/outlet branch and see them.

henry

2016-06-08 19:34

manager   ~0006412

Do you see any problem when you use the builtin reader?

Svensen

2016-06-08 20:41

reporter   ~0006414

There are no internal triangles when I run "paraFoam -builtin", BUT there are some holes in a mesh surface.
These holes disappears when I switched off "Decompose polyhedra".

henry

2016-06-08 21:11

manager   ~0006415

I see lots of surface artifacts with the builtin reader and far fewer with the OpenFOAM reader unless the vtkPolyhedron option is used in which case I see the same artifacts with both readers because of the limitations for the VTK polyhedron implementation.

I am not sure how to view the issues you see.

Svensen

2016-06-09 08:09

reporter   ~0006416

I've attached the project files for you:https://yadi.sk/d/xPaGvBNRsN8SR

My OpenFOAM version is: dev-e8a49d8f5a66

Svensen

2016-06-13 21:14

reporter   ~0006440

henry, can you see the issues now ?

Svensen

2016-07-13 17:57

reporter   ~0006523

Any reply ?

wyldckat

2016-07-13 18:08

updater   ~0006524

Sorry, on my side it will take me a couple more weekends until I'm able to look into this properly.
If I remember correctly, the workaround for now is to not use the VTKPolyhedron option.

As for fixing this issue, my plan is to:
 1- Create a "biopsy" of one or two mesh locations that have this problem (same as I did on #1633).
 2- Diagnose if the problem is in ParaView/VTK or OpenFOAM.
 3- Provide a fix for OpenFOAM or ParaView/VTK, depending on the diagnosis.

I did check VTK's unit test code in early June and there are several cell types being tested for. I didn't manage to figure out if there is one already for 7 vertexes.
Furthermore, it might be related to a topological issue in the order of the vertexes, which requires studying the currently supported polyhedrons in VTK, to figure out on which side is the problem (OpenFOAM or VTK).

Svensen

2016-08-17 22:32

reporter   ~0006699

Any success ?

wyldckat

2016-08-24 01:50

updater  

wyldckat

2016-08-24 01:51

updater  

wyldckat

2016-08-24 01:51

updater  

wyldckat

2016-08-24 02:13

updater   ~0006733

I've finally managed to find some time and inspiration to take a better look into this. I'm using OpenFOAM 4.x (label 32-bit) and ParaView 5.0.1 with OpenFOAM's own reader, given it's still close enough to OpenFOAM-dev for this feature set.

The first news that I have is shown in the attached image "latest_versus_original_inside.png":

 - On the left, it shows the latest case that Svensen provided in comment #0006416.
 - On the right, it shows the original case from the original report.
 - This demonstrates that a lot of the rendering problems have been solved, but they were solved only because the mesh is clearly different.
 - Therefore, part of the problem was solved in the layer generation, when snappyHexMesh was upgraded to a more recent version.


The second news I have is something that lead me to report issue #2213, namely that I had forgotten back in #1633 to also provide a fix for "foamToVTK".
In other words, the second news is that:

  - Internal triangles are still showing up, many of which were already showing up in the original case;
  - These internal triangles are actually being shown due to a weird representation of a VTK_WEDGE.
  - In image "second_location_latest_poly_vs_decomp_inside_problem_example_01.png" is shown:

     - on the left the polyhedral representation of two cells that share a floating triangle between them;
     - on the right is the decomposed polyhedra, looking from inside the mesh;
     - the floating triangle on the right is the shared face between the two cells on the left side of the image.
     - the problem seems to be related to the right cell from the left side of the image, given that there is a face squished on that cell, which happens to be represented as a VTK_WEDGE.

  - In image "second_location_latest_poly_vs_decomp_inside_problem_example_02.png" is shown:

     - almost the same as the previous image, but with a slight change of camera, to give a better 3D depth perspective;
     - on the right side of the image are shown the edges (in pink) for the two decomposed cells that have faces shared with the boundary and near the floating triangle;
     - as shown there, this problem does not seem to be related to a specific polyhedral cell, it seems to be related to a 5 point cell that is misrepresented.


The reason why I'm reporting the findings so far, is mostly because I haven't figured out a solution yet, given that this kind of cell shape may or may not be real... although preliminary analysis on the sibling cell that shares this flat face, does seem to represent the same shape.
Furthermore, I'm still trying to figure out the best "biopsy" mesh to be provided here, for consolidating the findings, given that it's not easy to have few cells and still be able to look into the mesh from within.


@Svensen: Are you seeing any other issues besides this one, when using your build of OpenFOAM-dev and ParaView 5.0.1?

wyldckat

2016-08-24 20:54

updater  

after_solving_problem.png (59,001 bytes)
after_solving_problem.png (59,001 bytes)

wyldckat

2016-08-24 20:55

updater  

snap_internal_triangles_dev_small.tar.gz (73,671 bytes)

wyldckat

2016-08-24 20:57

updater  

wyldckat

2016-08-24 21:37

updater   ~0006758

I've finally managed to figure out what the exact problem is and the simplest fix is to use VTKPolyhedron representation for "tetWedge" cells. I'll have the patches up for the next comment, but right now I'll report on my findings:

1. Inside the package "snap_internal_triangles_dev_small.tar.gz" is a biopsy of one of the parts of the mesh that has problems (it's either near the inlet or outlet, not sure which).
It's based on the most recent mesh that Svensen provided.
This biopsy case provides the following data:

  - Time snapshot 10 provides a large biopsy of the region that I used to analyse the problem. This makes it easier to have a camera inside it pointing outside and therefore seeing the problem triangles.

  - Time snapshot 15 provides a smaller biopsy, focusing only on the cells around one of the incorrectly rendered triangles.

  - The file "sample_cells_view.pvcc" is a camera view file, which can be loaded through the tiny camera icon on the 3D view widget. This view focuses on the diagnosed triangle.

  - The file "sample_cells_view_b.pvcc" is another camera view file, which will point at various triangles that are part of the time snapshot 10.

  - Inside the folder VTK are the files that were exported with "foamToVTK -poly" and which should render properly. It includes the file "cellpick_0.vtk", which shows only the problematic cell, although it's the one exported as a polyhedron.

  - Inside the root folder are a few "*.obj" files, which were exported with "writeMeshObj". From those, the file "meshFaceCentres_15.obj" is the most interesting one, since it reveals the centre of the collapsed face of this "tetWedge". We have to use the "Glyph" filter (with "Sphere" glyphs and 0.1 in size) to see them. More details below, as this is provided in the image "curious_face_centre_misaligned.png" as well.


2. In the image "after_solving_problem.png" is a representation of the decomposed polyhedra (left) versus VTKPolyhedron renders, when using the patched code (i.e. use polyhedron for "tetWedge"). As it can be seen, the problem still occurs for the decomposed cells, but at least the polyhedron representation is now correct (or at least it makes it look like it).


3. In the image "curious_face_centre_misaligned.png" is shown the diagnosed cell and centres of the faces from 2 points of view.

  - Don't mind the spheres that are clearly outside of the cell (and those with the red X). Instead, I want to focus on the sphere to which the red arrows that are pointing to.

  - This demonstrates that the face centre that OpenFOAM sees for this "tetWedge" is different from the one that ParaView can render. This seems to be a limitation in ParaView/VTK, which does not have a simple/reasonable solution.

  - Furthermore, I'm not even certain what it should really look like when rendered in 3D... it feels like it should have the profile of a saddle shape...


4. The reason why the bad triangles show up inside the mesh when rendering OpenFOAM's "tetWedge" cell shapes, is because the only closest simpler geometrical render is to use (without decomposing) is the VTK_WEDGE cell shape (see http://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf ). But the trick has been to have an edge collapse on itself, so that we can have only 4 faces, instead of the 5 faces that VTK_WEDGE uses by default.

  - The problem is that VTK_WEDGE has 6 vertexes, 2 triangles and 4 quadrangles, where neither triangles share an edge, which "tetWedge" does.

  - By collapsing any edge, we are never able to have the 2 triangles sharing an edge, which is required by OpenFOAM's "tetWedge".

  - The consequence of collapsing only one edge is that we get:

       - 1 triangle that was collapsed and is rendered as a line;
       - 1 quadrangle that has an edge collapsed, resulting in a triangle being rendered... and it's this triangle that shows up inside the mesh.

  - I tried using a VTK_PYRAMID, which has 5 vertexes (as does "tetWedge"), 1 quadrangle and 4 triangles, but I always got 2 triangles showing up inside the mesh. From what I can deduce, this is because there was no matching face inside the mesh, for these faces to be hidden.


5. I've also analysed what the built-in reader does within ParaView/VTK and it does the following:

  - When decomposing the polyhedra cells, it also decomposes the "tetWedge" cells. This is something that I have not been able to use out-of-the-box in foamToVTK, probably because there has never been a need for this decomposition in OpenFOAM.

  - When using VTKPolyhedron, it uses the polyhedron render for the "tetWedge" cells.


6. After solving this issue, there was at least one other representation that failed in the latest large mesh:

  - Tiny triangles might still show up when looking from the inside, but these are actually the consequence of the VTKPolyhedron rendering.

  - When using polyhedra decomposition, it was able to properly render what the original cell is shaped-like in that location for the triangle artefact was appearing.

  - This issue is a limitation in ParaView/VTK and it's not something easy to solve, given that it's due to a slight internal bend of one face.

  - The one cell I found today with this characteristic has 7 vertexes, but it seems that it was just a coincidence, given that the original case provided by Svensen had a lot more problems.


OK, I think this is all for this report. I'll provide the patch for sorting this out in "foamToVTK" and "PV*Readers" as soon as possible.

wyldckat

2016-08-24 21:51

updater  

render_tetWedge_as_polyhedron_v1.tar.gz (4,908 bytes)

wyldckat

2016-08-24 22:00

updater   ~0006759

Attached is the package "render_tetWedge_as_polyhedron_v1.tar.gz" that provides the fix for the following files:

  applications/utilities/postProcessing/dataConversion/foamToVTK/foamToVTK/vtkTopo.C
  applications/utilities/postProcessing/graphics/PV3Readers/PV3FoamReader/vtkPV3Foam/vtkPV3FoamMeshVolume.C
  applications/utilities/postProcessing/graphics/PVReaders/PVFoamReader/vtkPVFoam/vtkPVFoamMeshVolume.C

The fix is somewhat simplistic, but at least it solves the critical part of the problem: render "tetWedge" cells as polyhedrons, when the option is turned on; otherwise, use the old render method, by using a one-edge collapsed "VTK_WEDGE".
This patch can be applied to OpenFOAM 4.x and OpenFOAM-dev.


@Henry: I didn't add the following description in the code, given that it was as large or larger than the code block itself. Therefore, please include the following text in the commit message, for future reference:

  Problems when using VTK_WEDGE:

  - There will be triangles rendered inside the mesh (when surface-rendering),
  because one of the cell's triangles is defined as a quadrangle in VTK_WEDGE.

  - Therefore, this VTK_WEDGE representation is only used when
  decomposing the mesh, otherwise the correct representation is done by
  VTK_POLYHEDRON.

  - Furthermore, using VTK_PYRAMID gave worse result, because it renders 2
  triangles inside the mesh for the collapsed quadrangle, likely due to
  mismatch with the adjacent cell's face.

  - Using VTK_HEXAHEDRON was not tested in this iteration, given that it should
  give even worse results, when compared to using VTK_PYRAMID.

henry

2016-08-24 22:09

manager   ~0006760

Thanks Bruno

Resolved in OpenFOAM-dev by commit 22722a877c1c8170b527b40265fad259f32333cc
Resolved in OpenFOAM-4.x by commit 5c32f339e35056b648576fc6f16ac5428fa0a132

Issue History

Date Modified Username Field Change
2016-05-25 13:48 Svensen New Issue
2016-05-25 15:50 Svensen File Added: ParaView 4.4.0 64-bit_019.png
2016-05-25 15:51 Svensen File Added: ParaView 4.4.0 64-bit_020.png
2016-05-26 02:56 wyldckat Note Added: 0006324
2016-05-26 02:57 wyldckat File Added: comparison_OF22x.jpg
2016-05-26 02:57 wyldckat File Added: comparison_OF30x.png
2016-06-05 09:39 Svensen Note Added: 0006372
2016-06-05 14:27 henry Note Added: 0006373
2016-06-05 17:55 Svensen Note Added: 0006374
2016-06-05 18:15 henry Note Added: 0006375
2016-06-06 15:15 wyldckat Note Added: 0006384
2016-06-06 15:45 henry Note Added: 0006387
2016-06-06 16:27 wyldckat Note Added: 0006390
2016-06-08 17:57 Svensen Note Added: 0006410
2016-06-08 19:34 henry Note Added: 0006412
2016-06-08 20:41 Svensen Note Added: 0006414
2016-06-08 21:11 henry Note Added: 0006415
2016-06-09 08:09 Svensen Note Added: 0006416
2016-06-13 21:14 Svensen Note Added: 0006440
2016-07-13 17:57 Svensen Note Added: 0006523
2016-07-13 18:08 wyldckat Note Added: 0006524
2016-08-17 22:32 Svensen Note Added: 0006699
2016-08-24 01:46 wyldckat Relationship added related to 0002213
2016-08-24 01:50 wyldckat File Added: latest_versus_original_inside.png
2016-08-24 01:51 wyldckat File Added: second_location_latest_poly_vs_decomp_inside_problem_example_01.png
2016-08-24 01:51 wyldckat File Added: second_location_latest_poly_vs_decomp_inside_problem_example_02.png
2016-08-24 02:13 wyldckat Note Added: 0006733
2016-08-24 20:54 wyldckat File Added: after_solving_problem.png
2016-08-24 20:55 wyldckat File Added: snap_internal_triangles_dev_small.tar.gz
2016-08-24 20:57 wyldckat File Added: curious_face_centre_misaligned.png
2016-08-24 21:37 wyldckat Note Added: 0006758
2016-08-24 21:51 wyldckat File Added: render_tetWedge_as_polyhedron_v1.tar.gz
2016-08-24 22:00 wyldckat Note Added: 0006759
2016-08-24 22:01 wyldckat Assigned To => henry
2016-08-24 22:01 wyldckat Status new => assigned
2016-08-24 22:09 henry Note Added: 0006760
2016-08-24 22:09 henry Status assigned => resolved
2016-08-24 22:09 henry Fixed in Version => 4.x
2016-08-24 22:09 henry Resolution open => fixed
2016-08-26 00:58 wyldckat Relationship added related to 0002219