Re: [Libmesh-devel] Exodus export for HEX27 broken

[Martin L. <lu...@va...>]

Hi John

John Peterson writes:
 > On Fri, Aug 8, 2008 at 11:28 AM, John Peterson <jwp...@gm...> wrote:
 > > On Fri, Aug 8, 2008 at 10:46 AM, Derek Gaston <fri...@gm...> wrote:
 > >> The exodusII-4.pdf file available here http://sourceforge.net/project/showfiles.php?group_id=146943
 > >>  has the specification in Table 2 on page 24.
 > >
 > > Cool, that table implies the positions of the mid-face nodes on the
 > > preceding Hex20 diagram.  I think Hex27 use to work in Libmesh... that
 > > would have been our element of choice back in the old days.  Not sure
 > > what might have changed since then.
 > >
 > >> Who's familiar enough with libMesh's Hex27 node ordering to decipher
 > >> what's in the code and compare it to this document?
 > >
 > > I'll take a look at it hopefully today.  I'm responsible for building
 > > a boost RPM on lonestar ... not sure how long that's gonna take ;-)
 > 
 > I'm convinced the current hex27_node_map is wrong.  The first 20 node
 > indices should match LibMesh's exactly, as far as I can tell.  This
 > means that the first 20 locations in the hex27_node_map should be the
 > identity map, i.e. {0,1,2,...,19}  The last seven I calculate to be
 > (zero-based) {21, 25, 24, 26, 23, 22, 20}.  I'll give this a try and
 > check it in if it fixes the problem.

21, 25, 24, 26, 23, 22, 20

That's what I just tried... and it fails badly. So either we don't understand
what the documentation says, or Paraview has a broken import Filter. Maybe
someone with a software that produces a HEX27 could look at what it creates.

Maybe trial and error is the way to go...

 > I'd like to refactor this code a bit while I'm at it ... parts of it I
 > wrote in 2002 and it shows :-P  For example, dynamic memory allocation
 > is used in several places where, as far as I can tell, it's not
 > necessary.
 
That sounds reasonable, thanks a lot.

Best, Martin