[Paraview] [EXTERNAL] bug in ExodusII reader for general polyhedral meshes

Tue Apr 5 16:59:58 EDT 2016

Ethan/ all,
Good catch, good research.  Since this is an Exodus bug, and thus will affect Sandia, I wrote it up in the bug tracker.  I also took it as a Sandia bug.  Unless things change, it is scheduled to be fixed for the next release - version 5.1.

You can keep up with this bug here:  http://www.paraview.org/Bug/view.php?id=16062.

Alan

From: ParaView [mailto:paraview-bounces at paraview.org] On Behalf Of Coon, Ethan
Sent: Tuesday, April 05, 2016 12:42 PM
To: paraview at paraview.org
Subject: [EXTERNAL] [Paraview] bug in ExodusII reader for general polyhedral meshes

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
--------------------------------------------------------------

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" <ecoon at lanl.gov<mailto:ecoon at lanl.gov>>
Date: Wednesday, March 16, 2016 at 10:52 AM
To: "Sjaardema, Gregory D" <gdsjaar at sandia.gov<mailto:gdsjaar at sandia.gov>>
Cc: "Garimella, Rao Veerabhadra (LANL)" <rao at lanl.gov<mailto:rao at lanl.gov>>, "Vijay S. Mahadevan
[vijay.m at gmail.com<mailto:vijay.m at gmail.com>]" <vijay.m at gmail.com<mailto:vijay.m at gmail.com>>, "Grindeanu, Iulian R.
[iulian at mcs.anl.gov<mailto:iulian at mcs.anl.gov>]" <iulian at mcs.anl.gov<mailto:iulian at mcs.anl.gov>>, "markmiller at llnl.gov<mailto:markmiller at llnl.gov>"
<markmiller at llnl.gov<mailto:markmiller at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160405/dab836f9/attachment.html>