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

[Tim Tautges]

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