Ok, I took a look to the vtkExodusIIReader and there is no support for more than first order WEDGES.
VTK_TRIQUADRATIC_HEXAHEDRON (hex27) requires a different path but the code is a bit convoluted and I don't understand the numbering.

Thanks for help

2010/4/27 Derek Gaston <friedmud@gmail.com>
Ok - this is definitely a bug in Paraview.  I just wrote a Hex27 mesh out straight from Cubit and opened it with Paraview... and.... Paraview messes it up!  The file looks perfectly fine in Ensight... but Paraview has face nodes in an obviously wrong order.

How can this be though?  Paraview and Exodus are both developed at Sandia... and I have personally used codes at Sandia to output Hex27 meshes and view them in Paraview without trouble (although that was a few years ago).  Is it really possible that Paraview has a bug of this magnitude in it?  That is really hard for me to believe...


On Apr 27, 2010, at 10:30 AM, John Peterson wrote:

On Tue, Apr 27, 2010 at 11:19 AM, Lorenzo Botti <bottilorenzo@gmail.com> wrote:
The ordering of mid-face nodes and centroid that works with paraview is 26,
20, 25, 24, 22, 21, 23 but it is absolutely non-sense for me.
Your ordering is good for IO but for some reason I don't understand I need
to do a mesh.prepare_for_use() before adding the mesh to equation_systems.
Otherwise I get a seg fault.
I'm quite disappointed because even the prism18 is broken in paraview.
I think the problem is the vtk exodus reader.

Maybe we can work around this, perhaps by adding a user-selectable
flag in exodusII_io_helper which can switch the Hex27 node ordering
when the user knows the exodus files will be read with vtk/paraview?

For reading in those same files back to Libmesh, I'm not sure.  We
could have it try one ordering, check the Jacobian sign and if
negative, try the other ordering?  Seems like a pain ...


Libmesh-devel mailing list