1. CSE351/ IT351 Modeling And Simulation Choosing a Mesh Model Dr. Jim Holten

2. Choose a Model Object Representation  Finite Elements? (Pick from a zoo of predefined cell element types)  Regular Polyhedral Mesh? (Homogeneous mesh cells)  General Polyhedral Mesh? (Hierarchy of generalized cells)  Any combination of the above?

3. Model Cell Criteria  Cell shapes?  Cell properties (attributes)?  Cell associations with neighbor cells?  Cell associations with cells in other cell sets?  Complexities of developing supporting code?

4. Finite Element Cell Types  1-D: Line, interpolated line, spline  2-D: Triangle, rectangle, trapezoid, circle, ellipse, interpolated shape variations  3-D: Tetrahedral, hexahedral, spherical, ellipsoidal  Special types: Springs, shock absorbers, circuit components, other custom variations

5. Finite Element Attributes  Vertex coordinates (how many, what ordering)  Edges of a face?  Faces of a 3-D “zone”?  Adjacent element shared faces, edges, vertices?  Element volume, surface, face shapes?  Attributes over each of these?

6. Why Use Finite Elements?  Known common toolbox of elements (cell types).  Only a limited number of element (cell) types are needed.  Element interconnects well-defined and easily applied.  Problem at hand makes other approaches difficult.

7. Why NOT Use Finite Elements?  The needed element set (cell type) implementation is not already available.  The element set may need to be expanded.  May need to interface with models with other element types.  A generalized approach would reduce coding needs. -- N finite element types gives N^2 interfaces that may need implemented.  Parallel partitioning is complex and usually done by hand.

8. Regular Polyhedral Cell Types  Limited to “regular” shapes that will cover a “region”.  1-D: No problem.  2-D: Triangles, quadrangles, and hexagons only.  3-D: Hexahedrals only.  Does not cover irregularly shaped model objects/parts well.

9. Regular Polyhedral Cell Attributes  Neighbor interfaces are usually indicated through shared vertices, edges, and/or faces.  Index functions relate neighbors as in A(i,j) next to A(i, j-1).  Index functions relate cell hierarchies (points, edges, faces, and zones)

10. Why Use Regular Polyhedral Cells?  All cell attributes may be stored as simple vectors and arrays, using the corresponding indices of their parent cell.  Neighbors are easy to access (index functions).  Cell component hierarchies are easy to access (index functions).  The common cell forms used limits the algorithm variations needed.

11. Why NOT Use Regular Polyhedral Cells?  A regular “grid” doesn't fit the modeled part.  The model may be in several “parts” (subsets) of interest, such as interiors, surfaces, and boundary layers.  The model may need deformed or refined, and becomes incompatible with a regular grid representation.

12. General Polyhedral Cell Types  A hierarchy of cells (nodes, edges, faces, and zones).  0-D: node (point) has a location (usually)  1-D: edge (line) connects two end points (nodes).  2-D: face is surrounded by edges.  3-D: zone is surrounded by faces.  Fully generalized polyhedral shapes, allowing extreme shape representation.

13. General Polyhedral Cell Attributes  Nodes may have associated coordinates.  Other attribute values may be associated with any cell type and cell type element subsets, as needed.  Neighbor cells may be found through common (shared) faces, edges, or vertices.

14. Why Use General Polyhedral Cells  May approximate most shapes.  May be refined by substituting other cells for existing cells.  Relationships (subsetting, cell associations, etc) may be generalized to fit most needs.

15. Why NOT Use General Polyhedral Cells  No “special shapes” such as spheres, ellipsoids, cones, circles, etc.  Less rigidly organized, so representations are less standardized than the others.  More generalized algorithms can be slower or require more “control flags”.

16. Sets, Relations, and Fields (A metadata wrapper)  Set – any collection of members  Relation – a mapping as a collection of tuples relating members of its domain set to members of its range set.  Field – a collection of values (of a homogeneous type) associated with each member of its domain set.

17. Sets, Relations, and Fields  Set -- Indexed sets of elements  N elements  Reference members by their index in the set  Relation -- Indexed mappings between sets are similar to sparse adjacency matrices  Field – Homogeneous collection of attribute values (properties), one for each set member

18. Sets, Relations, and Fields (A metadata wrapper)  May represent any combination of cells from any of the other three approaches.  Can easily encapsulate or replace the representations of each of them.  Uses well-defined algebraic operations for relation, set, and fields to describe association derivations and time-step behaviors.

19. Sets, Relations, and Fields Cell Attributes  A “field” is a collection of attribute values, one for each member of the parent set and can contain property metadata such as data type, units, and representation forms.  A field “value” may be a simple real (float or double), integer, enumerated variable value, string, vector, matrix, tensor, or specialized structure.  A set may have one or many fields over it. Multiple fields can define all the attributes for a homogeneous cell set.

20. Why Use Sets, Relations, and Fields  Allows mixing mesh model types (and other elements types) in a single model.  Included metadata can prevent data misinterpretations.  Objects, their relationships, and their behaviors can all be described using the SRF algebra.  SRF Algebra can easily define and be implemented to automatically project a parallel partitioning onto complex mesh combinations, including generating all communications maps.

21. Why NOT Use Sets, Relations, and Fields  In early stages, so there aren't many developers familiar with it.  Inherits some drawbacks from the mesh forms you choose to include in your model.

22. Wide Application  Particle cloud, flock, and herd models  Generalized object collections  Mesh models, including cell hierarchies  Commonality of representation allows generalization of operators and I/O  Standardized higher level structure representation allows easier understanding  “Field algebras” are possible.

23. Sets, Relations, and Fields Parallel Partitioning  Partitioning is just relational operations on sets  Arbitrary numbers of partitions are possible  Simplifies load balance calculations  Enables dynamic partitioning (on-the-fly, as needed load migration)

24. Partitioning Matrix Mesh Models  Divide each matrix “index axis”: (the i and j are the axes in A(i, j)  Each axis gets an integer “divisor”, xd or yd  The number of partitions is (xd * yd)  The matrix is subdivided along the “index axes”  All vectors need subdivided into  “local” data (used only in this partition)  “shared” data (must be made available to other partitions)