View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0016062ParaView(No Category)public2016-04-05 16:512016-08-12 10:00
ReporterAlan Scott 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target Version5.1Fixed in Version 
Summary0016062: Exodus II reader for general polyhedral mesh bug
DescriptionThere 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.

"A supercomputer is a device for turning compute-bound problems into
I/O-bound problems”

From: "Coon, Ethan" <>
Date: Wednesday, March 16, 2016 at 10:52 AM
To: "Sjaardema, Gregory D" <>
Cc: "Garimella, Rao Veerabhadra (LANL)" <>, "Vijay S. Mahadevan
[]" <>, "Grindeanu, Iulian R.
[]" <>, ""
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 [^])
- 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?



TagsNo tags attached.
Topic Name
Typeincorrect functionality
Attached Files? file icon example_layout1.exo [^] (3,440 bytes) 2016-04-05 16:51
? file icon example_layout2.exo [^] (3,140 bytes) 2016-04-05 16:52


Alan Scott (manager)
2016-04-05 16:53

Note - Files were attached to an e-mail to the e-mail site by Ethan Coon, LANL.
Kitware Robot (administrator)
2016-08-12 10:00

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current ParaView Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2016-04-05 16:51 Alan Scott New Issue
2016-04-05 16:51 Alan Scott File Added: example_layout1.exo
2016-04-05 16:52 Alan Scott File Added: example_layout2.exo
2016-04-05 16:53 Alan Scott Note Added: 0035874
2016-04-05 16:53 Alan Scott Target Version => 5.1
2016-08-12 10:00 Kitware Robot Note Added: 0039027
2016-08-12 10:00 Kitware Robot Status backlog => closed
2016-08-12 10:00 Kitware Robot Resolution open => moved
2016-08-12 10:00 Kitware Robot Assigned To => Kitware Robot

Copyright © 2000 - 2018 MantisBT Team