Moving discussion to devel list. Is that after you reverted my changes?
We definitely read Hex27's without issues around here. Writing is another story. That said... I'm not happy with the Hex27 numbering... I know it's not right with Paraview. I worked on it for a while and as far as I can tell what I have in code right now matches both libMesh and Exodus documentation. BUT... I must be wrong because it's obviously not quite working correctly. One issue is that it appears to be fine in Ensight... but not Paraview... and if I try to fix it in Paraview then it breaks when I try to read a mesh in. I wondered a while ago if Cubit, Paraview and Ensight were all using the same Exodus standard... but there really isn't a way to know. I highly doubt that's the problem though. Let's get this figured out once and for all. If you want to take a swipe at an ordering... that would be awesome. I'll definitely check any code you want me to. I'll also work here and see if I can spot something that I haven't before. Derek On Apr 27, 2010, at 3:57 AM, Lorenzo Botti wrote: > If I try to read a hex 27 file written with exodusII I get a negative > jacobian... > There could be a problem with connectivity. > With hex20 everything works fine. > > Lorenzo > > ---------- Forwarded message ---------- > From: Lorenzo Botti <[email protected]> > Date: 2010/4/27 > Subject: Re: [Libmesh-users] problem with exodusII, hex27 and paraview > To: John Peterson <[email protected]> > > > Dear John, > thank you for the reply. > > I've already tried the old version of the connectivity but it > doesn't work > with paraview. > The ordering seems correct so I guess you are able to read a > exodusII mesh > with hex27 elements. > > Lorenzo > > > 2010/4/26 John Peterson <[email protected]> > > On Mon, Apr 26, 2010 at 2:18 PM, Lorenzo Botti > <[email protected]> >> wrote: >>> Hi all, >>> I noticed a problem in the visualization (with paraview) of hex27 >> elements written using exodusII_IO. >>> The connectivity is broken resulting in a corrugated surface. >>> I took a look at the patran documentation, nodes numbering as well >>> as >> face numbering seems correct to me. >>> >>> Is someone else aware of this problem? Could it be a vtk problem? >>> Can I read exodus files with others open source visualization tools? >> >> We've had problems with the Hex27 numbering in ExodusII before. It >> looks like Derek was the last one to change the indices around...here >> are the diffs from that version: >> >> svn diff -r3391:3462 exodusII_io_helper.C >> >> const int ExodusII_IO_Helper::ElementMaps::hex27_node_map[27] = { >> // Vertex and mid-edge nodes >> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, >> 19, >> // Mid-face nodes and centroid >> - 26, 21, 22, 23, 24, 25, 20}; >> + 21, 25, 24, 26, 23, 22, 20}; >> >> -const int ExodusII_IO_Helper::ElementMaps::hex27_face_map[6] = {1, >> 0, 3, 5, 4, 2}; >> +const int ExodusII_IO_Helper::ElementMaps::hex27_face_map[6] = {1, >> 2, 3, 4, 0, 5}; >> >> -const int ExodusII_IO_Helper::ElementMaps::hex27_inverse_face_map[6] >> = {2, 1, 6, 3, 5, 4}; >> +const int ExodusII_IO_Helper::ElementMaps::hex27_inverse_face_map[6] >> = {5, 1, 2, 3, 4, 6}; >> >> You might try reverting them and see if that helps? Perhaps paraview >> is going off an older Exodus numbering scheme. >> >> -- >> John >> > ------------------------------------------------------------------------------ > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
