<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hello,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>How/where should this be fixed? </div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Ethan</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>— </div>
<div><span style="font-family: Verdana; font-size: small;">--------------------------------------------------------------</span></div>
<div>
<div style="font-family: Tahoma; font-size: 13px;"><font face="Verdana" size="2">Ethan Coon<br>
Research Scientist<br>
Computational Earth Sciences -- EES-16<br>
Los Alamos National Laboratory<br>
505-665-8289<br>
<br>
</font><font face="Verdana" size="2">http://www.lanl.gov/expertise/profiles/view/ethan-coon</font><font face="Verdana" size="2"><a href="https://mymail.lanl.gov/ecp/Customize/redir.aspx?C=EYTyoFLRN0KpSCb8HNnAI5EfC_Qfws8Iuxxx4BGy4Wbt7_iUuRifrnA1vyJbHgXsVlp18WCFniw.&URL=http%3a%2f%2fwww.ldeo.columbia.edu%2f%7eecoon%2f" target="_blank"></a><br>
--------------------------------------------------------------</font></div>
</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div style="font-family: Consolas;">On 03/16/16 12:08, Sjaardema, Gregory D wrote:</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">The correct representation is closeer to layout 2. The faces are referenced</div>
<div style="font-family: Consolas;">in a “file implicit” id—basically the same way that elements are referenced</div>
<div style="font-family: Consolas;">in sideset definitions. (This is what you refer to as “global” numbering,</div>
<div style="font-family: Consolas;">but I typically use global ids to refer to the ids generated by the maps;</div>
<div style="font-family: Consolas;">the implicit ordering is the 1..num_entity based on the definition order in</div>
<div style="font-family: Consolas;">the file). The implicit id relies on the order of the face blocks in the</div>
<div style="font-family: Consolas;">file and the order of the faces within the blocks.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">The primary difference from your layout 2 is that you can have multiple face</div>
<div style="font-family: Consolas;">blocks. For example, you could define a face block with QUAD faces and then</div>
<div style="font-family: Consolas;">another face block with your 5-gons (NSIDED) and then your element blocks</div>
<div style="font-family: Consolas;">could refer to faces from either of the face blocks. You can also have</div>
<div style="font-family: Consolas;">multiple arbitrary-polygon face blocks.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">You are correct that the layout 1 causes invalid meshes due to “duplicated”</div>
<div style="font-family: Consolas;">faces on the interface between contiguous element blocks. However, exodus</div>
<div style="font-family: Consolas;">won’t recognize them as duplicated and instead it will refer to two</div>
<div style="font-family: Consolas;">coincident but distinct faces.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">I think much of the confusion comes from the scarcity of documentation on</div>
<div style="font-family: Consolas;">the exodus arbitrary polyhedra capabilty and that there is typically only a</div>
<div style="font-family: Consolas;">single test mesh in the test suite and it only has a single element block.</div>
<div style="font-family: Consolas;">I will try to get some time to generate some additional polyhedra tests and</div>
<div style="font-family: Consolas;">the documentation, but not sure when I can get to it.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">If anyone sees a reason why the multi-face-block-layout-2 does not make</div>
<div style="font-family: Consolas;">sense, let me know.</div>
<div style="font-family: Consolas;">..Greg</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">--</div>
<div style="font-family: Consolas;">"A supercomputer is a device for turning compute-bound problems into</div>
<div style="font-family: Consolas;">I/O-bound problems”</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">From: "Coon, Ethan" <<a href="mailto:ecoon@lanl.gov">ecoon@lanl.gov</a>></div>
<div style="font-family: Consolas;">Date: Wednesday, March 16, 2016 at 10:52 AM</div>
<div style="font-family: Consolas;">To: "Sjaardema, Gregory D" <<a href="mailto:gdsjaar@sandia.gov">gdsjaar@sandia.gov</a>></div>
<div style="font-family: Consolas;">Cc: "Garimella, Rao Veerabhadra (LANL)" <<a href="mailto:rao@lanl.gov">rao@lanl.gov</a>>, "Vijay S. Mahadevan</div>
<div style="font-family: Consolas;">[<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>]" <<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>>, "Grindeanu, Iulian R.</div>
<div style="font-family: Consolas;">[<a href="mailto:iulian@mcs.anl.gov">iulian@mcs.anl.gov</a>]" <<a href="mailto:iulian@mcs.anl.gov">iulian@mcs.anl.gov</a>>, "<a href="mailto:markmiller@llnl.gov">markmiller@llnl.gov</a>"</div>
<div style="font-family: Consolas;"><<a href="mailto:markmiller@llnl.gov">markmiller@llnl.gov</a>></div>
<div style="font-family: Consolas;">Subject: [EXTERNAL] ExodusII and arbitrary polyhedra</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">Hi all, and especially Greg,</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">I've been working on a project that needs multi-material, arbitrary</div>
<div style="font-family: Consolas;">polyhedral meshes. After significant discussions with multiple people, I've</div>
<div style="font-family: Consolas;">discovered a few inconsistencies between how various software packages</div>
<div style="font-family: Consolas;">assume ExodusII files lay out these types of meshes. Clarification would be</div>
<div style="font-family: Consolas;">helpful so that these tools can work together!</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">Throughout I will use the motivating example, for which I've attached two</div>
<div style="font-family: Consolas;">ExodusII files, one in each layout:</div>
<div style="font-family: Consolas;">- 2 pentagonal-prisms (i.e. a 7-faced object, where the top and bottom faces</div>
<div style="font-family: Consolas;">are 5-gons, and all other faces are 4-gons, see</div>
<div style="font-family: Consolas;"><a href="https://en.wikipedia.org/wiki/Pentagonal_prism">https://en.wikipedia.org/wiki/Pentagonal_prism</a>)</div>
<div style="font-family: Consolas;">- 2 materials (one prism in each)</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">ExodusII file layout 1 (format assumed by Paraview/VisIt readers, which I</div>
<div style="font-family: Consolas;">believe are the same code? Maybe written/maintained by Mark?):</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">- two element blocks</div>
<div style="font-family: Consolas;">- two face blocks</div>
<div style="font-family: Consolas;">- each element block uses a "face id" that is implied by a block-local</div>
<div style="font-family: Consolas;">numbering of the faces in its face block. So in element block 2, we have:</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">facconn1 = 1, 2, 3, 4, 5, 6, 7 ;</div>
<div style="font-family: Consolas;">facconn2 = 1, 2, 3, 4, 5, 6, 7 ;</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">fbepecnt1 = 5, 5, 4, 4, 4, 4, 4 ;</div>
<div style="font-family: Consolas;">fbepecnt2= 5, 5, 4, 4, 4, 4, 4 ;</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">Effectively each of these are indices into their BLOCK list of faces.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">ExodusII file layout 2 (format assumed by MSTK, written/maintained by Rao):</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">- two element blocks</div>
<div style="font-family: Consolas;">- one or more face blocks</div>
<div style="font-family: Consolas;">- each element block uses a "face id" that is implied by a global numbering</div>
<div style="font-family: Consolas;">of the faces in all face blocks. So, in element block 2 we have:</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;"> facconn1 = 1, 2, 4, 6, 8, 10, 12 ;</div>
<div style="font-family: Consolas;"> facconn2 = 2, 3, 5, 7, 9, 11, 13 ;</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;"> fbepecnt1 = 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4 ;</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">with one and only one face_blk.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">This is often just one and only one face block, where all element block face</div>
<div style="font-family: Consolas;">lists refer to that same face block.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">Note that these two are mutually exclusive -- meshes built in layout 1 crash</div>
<div style="font-family: Consolas;">MSTK and meshes built in layout 2 crash Paraview/VisIt.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">I have a bit of an opinion here. The former may seem natural, in the sense</div>
<div style="font-family: Consolas;">that each element block has its own faces, but I think it results in</div>
<div style="font-family: Consolas;">not-well-posed meshes. In the former, the shared face at the interface of</div>
<div style="font-family: Consolas;">the two materials is listed twice -- it must exist in both face blocks. To</div>
<div style="font-family: Consolas;">me, the former is a specification for two independent (non-connected) meshes</div>
<div style="font-family: Consolas;">that share a boundary -- the boundary face is duplicated. It should be</div>
<div style="font-family: Consolas;">valid Exodus, but it should not refer to a topologically connected mesh. It</div>
<div style="font-family: Consolas;">is geometrically, but not topologically, degenerate. This is useful for</div>
<div style="font-family: Consolas;">things like fault modeling, where the domain really is a "punctured" domain</div>
<div style="font-family: Consolas;">and boundary conditions may be applied on both faces, independently. This</div>
<div style="font-family: Consolas;">should be distinguished from the typical case, where these are two layers in</div>
<div style="font-family: Consolas;">the same mesh, and there is only one face on the interface.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">The second recognizes that faces, like nodes, which are globally listed in a</div>
<div style="font-family: Consolas;">single block, are the interface between blocks, and they do not belong to</div>
<div style="font-family: Consolas;">either material 1 or material 2. It is both topologically and geometrically</div>
<div style="font-family: Consolas;">"degenerate" in the sense that both elements point to the same face.</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">Greg, can you weigh in here with your thoughts on which, or neither, is</div>
<div style="font-family: Consolas;">"correct?" And can a decision be made so that MOAB, Paraview, MSTK, and</div>
<div style="font-family: Consolas;">VisIt can all work with the same format? Anyone else have comments/thoughts</div>
<div style="font-family: Consolas;">on this? Is there anyone else that might care about this answer?</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">Thanks,</div>
<div style="font-family: Consolas;"><br>
</div>
<div style="font-family: Consolas;">Ethan</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div style="font-family:Tahoma; font-size:13px">
<blockquote type="cite" style="font-family:Times; font-size:medium"></blockquote>
</div>
</div>
</div>
</body>
</html>