From: John P. <jwp...@gm...> - 2008-08-08 22:36:28
|
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. 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. -- John |