Hello, 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? Thanks, Ethan — -------------------------------------------------------------- Ethan Coon Research Scientist Computational Earth Sciences -- EES-16 Los Alamos National Laboratory 505-665-8289 http://www.lanl.gov/expertise/profiles/view/ethan-coon<https://mymail.lanl.gov/ecp/Customize/redir.aspx?C=EYTyoFLRN0KpSCb8HNnAI5EfC_Qfws8Iuxxx4BGy4Wbt7_iUuRifrnA1vyJbHgXsVlp18WCFniw.&URL=http%3a%2f%2fwww.ldeo.columbia.edu%2f%7eecoon%2f> -------------------------------------------------------------- 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" <ec...@lanl.gov<mailto:ec...@lanl.gov>> Date: Wednesday, March 16, 2016 at 10:52 AM To: "Sjaardema, Gregory D" <gdsj...@sandia.gov<mailto:gdsj...@sandia.gov>> Cc: "Garimella, Rao Veerabhadra (LANL)" <r...@lanl.gov<mailto:r...@lanl.gov>>, "Vijay S. Mahadevan [vija...@gmail.com<mailto:vija...@gmail.com>]" <vija...@gmail.com<mailto:vija...@gmail.com>>, "Grindeanu, Iulian R. [iul...@mcs.anl.gov<mailto:iul...@mcs.anl.gov>]" <iul...@mcs.anl.gov<mailto:iul...@mcs.anl.gov>>, "markmil...@llnl.gov<mailto:markmil...@llnl.gov>" <markmil...@llnl.gov<mailto:markmil...@llnl.gov>> 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? Thanks, Ethan
example_layout2.exo
Description: example_layout2.exo
example_layout1.exo
Description: example_layout1.exo
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview