|
|
ParaView 4.4.0 64-bit_019.png (156,628 bytes) |
|
|
ParaView 4.4.0 64-bit_020.png (234,598 bytes) |
|
|
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 ;) |
|
|
|
|
|
comparison_OF30x.png (104,905 bytes) |
|
|
wyldckat, do you have any success ? |
|
|
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? |
|
|
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... |
|
|
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? |
|
|
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". |
|
|
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? |
|
|
> 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. |
|
|
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. |
|
|
Do you see any problem when you use the builtin reader? |
|
|
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". |
|
|
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. |
|
|
I've attached the project files for you:https://yadi.sk/d/xPaGvBNRsN8SR My OpenFOAM version is: dev-e8a49d8f5a66 |
|
|
henry, can you see the issues now ? |
|
|
Any reply ? |
|
|
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). |
|
|
Any success ? |
|
|
latest_versus_original_inside.png (59,430 bytes) |
|
|
|
|
|
|
|
|
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? |
|
|
after_solving_problem.png (59,001 bytes) |
|
|
|
|
|
curious_face_centre_misaligned.png (38,916 bytes) |
|
|
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. |
|
|
|
|
|
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. |
|
|
Thanks Bruno Resolved in OpenFOAM-dev by commit 22722a877c1c8170b527b40265fad259f32333cc Resolved in OpenFOAM-4.x by commit 5c32f339e35056b648576fc6f16ac5428fa0a132 |
- Anonymous
