Exodus II reader for general polyhedral mesh bug
Edit -- Summary (details below): Polyhedra face references should be treated as file-scope implicit ids instead of indices into a specific face block.
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
There is a bug in the Exodus II reader. This excellent e-mail thread explains it, and there are two examples referenced that I have included.
After discussion with a lot of meshing people, and especially Greg Sjaardema at SNL, the ExodusII lead, I believe there is a bug in the ExodusII reader for the case of arbitrary polyhedra.
Below is an extremely detailed description of the issue, along with a response by Greg explaining what is correct for Exodus. Effectively the current reader expects that there are the same number of face blocks as element blocks in the arbitrary polyhedral format, and this is not the correct data layout of an ExodusII file. I’ve attached two files — example_layout1.exo which is incorrect ExodusII format but works in Paraview, and example_layout2.exo which is correct ExodusII but crashes Paraview.
How/where should this be fixed?
Ethan Coon Research Scientist Computational Earth Sciences -- EES-16 Los Alamos National Laboratory 505-665-8289
On 03/16/16 12:08, Sjaardema, Gregory D wrote:
The correct representation is closeer to layout 2. The faces are referenced in a “file implicit” id—basically the same way that elements are referenced in sideset definitions. (This is what you refer to as “global” numbering, but I typically use global ids to refer to the ids generated by the maps; the implicit ordering is the 1..num_entity based on the definition order in the file). The implicit id relies on the order of the face blocks in the file and the order of the faces within the blocks.
The primary difference from your layout 2 is that you can have multiple face blocks. For example, you could define a face block with QUAD faces and then another face block with your 5-gons (NSIDED) and then your element blocks could refer to faces from either of the face blocks. You can also have multiple arbitrary-polygon face blocks.
You are correct that the layout 1 causes invalid meshes due to “duplicated” faces on the interface between contiguous element blocks. However, exodus won’t recognize them as duplicated and instead it will refer to two coincident but distinct faces.
I think much of the confusion comes from the scarcity of documentation on the exodus arbitrary polyhedra capabilty and that there is typically only a single test mesh in the test suite and it only has a single element block. I will try to get some time to generate some additional polyhedra tests and the documentation, but not sure when I can get to it.
If anyone sees a reason why the multi-face-block-layout-2 does not make sense, let me know. ..Greg
-- "A supercomputer is a device for turning compute-bound problems into I/O-bound problems”
From: "Coon, Ethan" firstname.lastname@example.org Date: Wednesday, March 16, 2016 at 10:52 AM To: "Sjaardema, Gregory D" email@example.com Cc: "Garimella, Rao Veerabhadra (LANL)" firstname.lastname@example.org, "Vijay S. Mahadevan [email@example.com]" firstname.lastname@example.org, "Grindeanu, Iulian R. [email@example.com]" firstname.lastname@example.org, "email@example.com" firstname.lastname@example.org Subject: [EXTERNAL] ExodusII and arbitrary polyhedra
Hi all, and especially Greg,
I've been working on a project that needs multi-material, arbitrary polyhedral meshes. After significant discussions with multiple people, I've discovered a few inconsistencies between how various software packages assume ExodusII files lay out these types of meshes. Clarification would be helpful so that these tools can work together!
Throughout I will use the motivating example, for which I've attached two ExodusII files, one in each layout:
- 2 pentagonal-prisms (i.e. a 7-faced object, where the top and bottom faces are 5-gons, and all other faces are 4-gons, see https://en.wikipedia.org/wiki/Pentagonal_prism)
- 2 materials (one prism in each)
ExodusII file layout 1 (format assumed by Paraview/VisIt readers, which I believe are the same code? Maybe written/maintained by Mark?):
- two element blocks
- two face blocks
- each element block uses a "face id" that is implied by a block-local numbering of the faces in its face block. So in element block 2, we have:
facconn1 = 1, 2, 3, 4, 5, 6, 7 ; facconn2 = 1, 2, 3, 4, 5, 6, 7 ;
fbepecnt1 = 5, 5, 4, 4, 4, 4, 4 ; fbepecnt2= 5, 5, 4, 4, 4, 4, 4 ;
Effectively each of these are indices into their BLOCK list of faces.
ExodusII file layout 2 (format assumed by MSTK, written/maintained by Rao):
two element blocks
one or more face blocks
each element block uses a "face id" that is implied by a global numbering of the faces in all face blocks. So, in element block 2 we have:
facconn1 = 1, 2, 4, 6, 8, 10, 12 ; facconn2 = 2, 3, 5, 7, 9, 11, 13 ;
fbepecnt1 = 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4 ;
with one and only one face_blk.
This is often just one and only one face block, where all element block face lists refer to that same face block.
Note that these two are mutually exclusive -- meshes built in layout 1 crash MSTK and meshes built in layout 2 crash Paraview/VisIt.
I have a bit of an opinion here. The former may seem natural, in the sense that each element block has its own faces, but I think it results in not-well-posed meshes. In the former, the shared face at the interface of the two materials is listed twice -- it must exist in both face blocks. To me, the former is a specification for two independent (non-connected) meshes that share a boundary -- the boundary face is duplicated. It should be valid Exodus, but it should not refer to a topologically connected mesh. It is geometrically, but not topologically, degenerate. This is useful for things like fault modeling, where the domain really is a "punctured" domain and boundary conditions may be applied on both faces, independently. This should be distinguished from the typical case, where these are two layers in the same mesh, and there is only one face on the interface.
The second recognizes that faces, like nodes, which are globally listed in a single block, are the interface between blocks, and they do not belong to either material 1 or material 2. It is both topologically and geometrically "degenerate" in the sense that both elements point to the same face.
Greg, can you weigh in here with your thoughts on which, or neither, is "correct?" And can a decision be made so that MOAB, Paraview, MSTK, and VisIt can all work with the same format? Anyone else have comments/thoughts on this? Is there anyone else that might care about this answer?