[MOAB-dev] Some questions upon embarking on a new MOAB Reader

[Paul Wilson]

Hi Tim

I have nearly completed a basic implementation of an ABAQUS reader  
with support for a limited set of keywords. (Those we need right now).  
I have done my best to structure it for support of additional keywords  
as the need arises.

In so doing, I have devised an answer to some of the questions that I  
have posed and will endeavor to create some documentation when it is  
ready.

Paul

-- --
Associate Professor, Nuclear Engineering
Chair, Energy Analysis & Policy
UW-Madison
wilsonp at engr.wisc.edu, 608.263.0807
Sent from my iPhone

On Aug 7, 2009, at 5:51 PM, Tim Tautges <tautges at mcs.anl.gov> wrote:

> Replying also to the moab-dev list, as (as you infer) it's of  
> general interest.
>
> Paul Wilson wrote:
>> Hi Tim,
>> Patrick has studied the ABAQUS input file description and we have  
>> discussed how to incorporate this into a reader.  A number of  
>> questions emerged, however.  I am not sure if this is appropriate  
>> for the moab-dev list as it may become an involved conversation,  
>> but I am happy to carry it out there (and have Patrick join that  
>> list).  Some of the paradigms we see here are likely to be in other  
>> file formats and their implementation in MOAB should probably  
>> conform to some kind of "master plan".
>> The ABAQUS format describes individual parts, each in their own  
>> local coordinate system, with a list of nodes and a list of  
>> elements.  The nodes and elements can be arranged in nodesets or  
>> elementsets, which are generally conveniences for applying  
>> materials, loads, etc.  In many cases, the node and element sets  
>> define material boundaries, but not always.  The file then  
>> describes assemblies, each of which has multiple instances of a  
>> subset of the parts, each transformed to the coordinate system of  
>> the assembly.
>
> The general question of how to represent assemblies of parts, which  
> is similar to how feature-based geometric modeling systems do  
> things, has not really been addressed (yet) in MOAB nor in CGM.   
> There are several important nuances and/or caveats:
>
> - If you have a mesh for each part, rather than each part instance  
> (or copy), then the question arises how you get a contiguous mesh  
> where parts meet (assuming their mesh in coincident).  Some codes  
> can handle non-conforming mesh like this, but in almost all cases  
> you sacrifice time and/or accuracy in the analysis.  If Abaqus  
> merges mesh together where appropriate, then the question arises how  
> to handle boundary conditions on the sides of such lattices.  If you  
> rule that out altogether, then it's easier but less generally  
> useful.  That makes me wonder whether the files have separate mesh  
> for part instances rather than for parts.
>
> - The assembly/part/part instance + transform hierarchy can and  
> should be represented in the resulting MOAB mesh, similar to how  
> it's done with geometric entities and topology.  I view the assembly/ 
> part/part instance graph as standing beside the geometric topology  
> graph, possibly with links between the two (e.g. in cases where a  
> part only has one instance).  I haven't explicitly handled the  
> notion of a transform embedded as a tag somewhere, but that's  
> clearly how one would do it.  Similarly, MOAB doesn't have direct  
> support for coordinate systems and transformations between them, but  
> that can easily be done at the application level for now if it's  
> critical.
>
> - In general, you want to separate the specification of materials  
> (in material sets) from the element representation itself; making  
> them the same thing is an artifact of the Exodus format, which  
> probably influenced Abaqus' data formats (their author came from  
> Sandia).  I've told you about this in the past, so this is more for  
> others' information.
>
>> Some basics of our recommended MOAB layout:
>> * each PART definition would be a meshset that is a child of the  
>> root set
>> * each PART could contain a set of nodes and elements
>> * each nodeset and element set would be a meshset that is a child  
>> of the PART meshset
>> * assignment of matieral properties, loads, etc, would conform to  
>> the manner in which they are defined in the file
>>   * if defined on a nodeset/elementset, that set would be tagged
>>   * if defined for a particular node/element, that node/element  
>> would be tagged
>> * each ASSEMBLY (not sure if we are like to see more than one)  
>> would be a meshset that is a child of the root set
>> * each instance of a PART would be a meshset (copy of PART meshset  
>> - see below) that is transformed to the ASSEMBLY's coordinate  
>> system and a child of the ASSEMBLY set
>
> As I said above, this gets much more complicated when you start  
> considering merging and non-manifold stuff.  Geometric modeling  
> systems almost always leave this to the mesh generation step, and  
> few mesh generation tools have very satisfactory ways of handling  
> this (often require manual "merging" by users).
>
>> Some questions:
>> 1. Are there examples in other readers of preserving this richness  
>> of hierarchy, etc?
>
> The closest thing is representing geometric topology.
>
>> 2. Copying meshsets/creating PART instances:
>>    a. Do we want to copy or use some other paradigm? I think we  
>> need to copy since nodes/elements will ultimately have different  
>> field values.
>
> In the near term, this will almost surely requiring copying.  In the  
> longer term, I'd love to do more of an implicit copy, where you  
> still represent the copy in handle space but reference their  
> connectivity/coordinate information from the source of the copy.   
> Field values would still be assigned to the copies, as dense tags.
>
>>    b. Is there infrastructure for copying a meshset and having its  
>> child meshsets be recreated automatically?  Since the copy, in this  
>> sense, will create new entities for the copied nodes/elements, the  
>> new child meshsets will need to refer to the new nodes/elements.   
>> Cross-referencing these could be complicated.
>
> Yep, it's complicated.  I've explored those issues a little bit in  
> MeshKit, but have yet to write it up anywhere.
>
> - tim
>
>> I think those are my only questions for now....  We will start  
>> implementing something today, so if you want to chat about this,  
>> let me know....
>> Paul
>
> -- 
> ================================================================
> "You will keep in perfect peace him whose mind is
>  steadfast, because he trusts in you."               Isaiah 26:3
>
>             Tim Tautges            Argonne National Laboratory
>         (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>         phone: (608) 263-8485      1500 Engineering Dr.
>           fax: (608) 263-4499      Madison, WI 53706
>