Re: [Libmesh-users] [Bug] Quad8 in unv_io

[<lu...@gi...>]

Steffen

Thanks for fixing this! A rapid test showed that it works for my
application. 

How should elements that are not in the standard UNV description be
encoded? Let's say I want to extend this for QUAD9, should I invent a
new element type (say, 300)?

Best, Martin

Steffen Petersen writes:
 > With the latest cvs version, the inconsistencies should be gone for
 > your example. The problem was that the conversion from unv
 > format to the libmesh numbering was somehow mixed up when writing
 > elements.
 > 
 > The 0 element and node ids should not hurt unless you try to import
 > the mesh to some other software using unv format.
 > If you read an unv mesh (e.g. ex8), the node ids given in the file
 > will be stored in the MeshData object (if MeshData::activate() was
 > called prior to reading the mesh) and maybe used later. Otherwise
 > we simply stick to the 0-based libmesh numbering.

 > > There seem to be some bugs in unv_io.C, that are hard to tackle. Part
 > > of the problem is, that I cannot find any definition of the
 > > node-numbering scheme in UNV, the other part the somewhat complicated
 > > implementation of the node-numbering, especially on read.
 > > 
 > > Here is what I found (using Quad8):
 > > 
 > > Writing the mesh, the node numbering is
 > > 
 > >          0         7         1         8         3         5         6         2
 > > 
 > > reading this exact mesh, and writing it again gives
 > > 
 > >          0         8         2         3         7         5         1         6
 > > 
 > > My guess is, that the reading causes the problem (I don't understand
 > > that part of the code). Then there is also the comment that UNV is
 > > 1-based, but there are nodes and elements named 0.