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

Wollaber, Allan B. awollaber at anl.gov
Tue Jan 13 16:19:58 CST 2009


Jason,

I had forgotten that I called both "iMesh_newMesh" and "iMesh_load".
Thanks for clearing that up.

I think we can rule out that someone has modified my local copy of MOAB,
since I installed it locally (in my home directory) using autoreconf
around mid-December.  

Let me know what you find out, or if I can do anything useful while you
figure out what's going on from your side.  

Thanks,
- Allan



-----Original Message-----
From: Jason Kraftcheck [mailto:kraftche at cae.wisc.edu] 
Sent: Tuesday, January 13, 2009 4:11 PM
To: Wollaber, Allan B.
Cc: moab-dev at mcs.anl.gov; Smith, Micheal A.; Tautges, Timothy J.
Subject: Re: [MOAB-dev] Possible bug in 2-D quadratic elements

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



More information about the moab-dev mailing list