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

[Jason Kraftcheck]

The current version of MOAB now has the following relevant changes:

o Remove "HIGHER_ORDER_ADJ" option for iMesh_newMesh
o Restore previous iMesh_getEntArrAdj behavior: return full
   connectivity list for higher-order elements
o Fix bug reading in higher-order face elements from CUB files.
o Fix incorrect connectivity order for tet8, tet14, and hex27
   elements read from CUB files.

The last item above may be an issue if you are working with those element
types (volume elements with mid-face nodes.)  MOAB's node ordering is not
the same as PATRAN or ExodusII for many higher-order element types.  The CUB
file reader was previously storing hex27 connectivity in the PATRAN rather
than MOAB order.  Further, it was storing tet8 and tet14 connectivity in an
order that was neither PATRAN/Exodus nor MOAB (some internal Cubit ordering
apparently.)

- jason



Wollaber, Allan B. wrote:
> 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
> 


-- 
"A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson