[MOAB-dev] Possible bug in 2-D quadratic elements

[Jason Kraftcheck]

Wollaber, Allan B. wrote:
> Jason,
> 
> Thank you for your prompt reply. 
> 
> Actually, I never call "iMesh_createMesh", and I can't find this
> function in any of the header files.  I'm working out of the trunk of
> MOAB (grep -ir createmesh *).  Do you possibly mean "iMesh_newMesh"?  I

Yes, I meant the latter.  Apologies for any confusion.

> would prefer to just use "iMesh_load", since I am just loading the mesh
> directly from the CUBIT file.  Would it be necessary to create a new
> mesh instance and copy in the mesh loaded from CUBIT to achieve this? If
> so, I'm actually not sure how best to do that.  Is there a "copy
> constructor" somewhere?

You need to call iMesh_newMesh to create the "iMesh_instance" object which
is later passed to iMesh_load.  The name "newMesh" is a bit misleading, as
it doesn't create a mesh (new or otherwise), but rather an instance of the
database.

> 
> Also, will using this setting affect the success I've had thus far with
> the quadratic 3-D elements? It is only the 2-D elements that I've had
> trouble with.
> 

It shouldn't.  But it appears that the problem is more complicated that I
had at first thought.  Apparently the version of MOAB you are using is
always returning the higher-order nodes from getEntArrAdj (regardless of any
setting.)  I don't know if the MOAB behavior has changed or if someone has
modified your copy of MOAB.  So the problem you are seeing is a bug rather
than an API issue.  I'm looking into this right now.  So far the problem
appears to be that the 'cub' file reader in MOAB looses the higher-order
nodes on the edges of face elements (thus 5 nodes for a quad9.)


- jason