Hi all,
I’m using ParaView to display meshes from Exodus II files. This works fine with versions 5.11.0 and below, but starting from version 5.12.0, not all mesh elements are displayed. I’ve attached screenshots of both the correctly and incorrectly displayed mesh, as well as the example model file used for these screenshots.
The issue is present on both Windows and Linux.
Any hint on what’s going wrong here would be greatly appreciated!
Hi @Stysch
It looks like half your cells are inverted (and most of them are declared as hexahedron but should be tetrahedron anyway).
It looks like ParaView nows try to “respect” inverted hexadron so they show up like this.
But you actually can fix your mesh in ParaView!
Add a Tetrahedralize and a CleanCellsToGrid filter to get your correct data (as tetrahedron):
Hi @mwestphal ,
thank you very much for your quick and helpful reply! Looks like an issue with our writer then, thanks for pointing that out.
I’ve looked into the code of our Exodus writer, and it seems to be intentional that tetrahedrons are written out as hexahedrons: The Exodus standard does not allow element blocks with mixed types, and because any collector of the mesh can contain both, the type with the maximum number of node is used for all elements.
This is of course not great, but it seems to me that the behavior of ParaView 5.11 fits better to this limitation of the Exodus format.
You said that the issue is not that we used hexas for tetras but rather that the hexas are “inverted”. What exactly do you mean by inverted? When we write a hexa from a tetra, we use the nodes of the tetra more than once. Maybe I could influence whether the elements are inverted by changing which tetra node is used where in the hexa?
Current mapping:
tetra0 → hexa0
tetra1 → hexa1
tetra1 → hexa2
tetra2 → hexa3
tetra3 → hexa4
tetra1 → hexa5
tetra1 → hexa6
tetra1 → hexa7
I think you need to invert the order of points of certain hexa, but more investigation is needed to understand exactly which one. You can use ParaView to identify which one. You can simply select an inverted hexa and check the point ordre in ParaView.
Thank you for your reply! Thinking more about this issue I’m even more confused. I still do not understand what an inverted element is in ParaView and I cannot find in the documentation.
We order the nodes of our terta and hexahedrons exactly as you do here. To ensure that our tetrahedrons which we save as hexas are displayed correctly, the only thing we need to make sure should be that each of the four faces of any tetrahedron becomes one of the faces of the hexahedron (because in the visualization “Surface” the faces should be what is displayed). If we use the node mapping I shared above, we should get the following face mapping:
hexa face 0 → tetra face 0
hexa face 1 → tetra face 3
hexa face 2 → tetra face 1
hexa face 3 → node 1 (all nodes of that face are node 1)
hexa face 4 → edge 1 2
hexa face 5 → tetra face 2
I don’t know where there is room for a different visualization here. I’d really like to understand what version 5.12 and newer are doing differently here.
The simplest way to figure that out is to bisect the commits of ParaView and VTK and figure out which change caused the issue.
Ok, thank you for the suggestion, I will maybe try to do that!
But could you maybe still write one to two sentences about what you meant by “inverted element” or how you came to the assessment that half of the elements fall in that category?
I think you understood correctly, I meant that the order of the point of the cells may be incorrect in the cell definition, which would cause the rendering issues.
