CSE351/ IT351 Modeling And Simulation

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

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 ElementCell 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 ElementAttributes • 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 UseFinite 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 UseFinite 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 PolyhedralCell 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 CellAttributes • 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 UseRegular 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 UseRegular 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 PolyhedralCell 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 PolyhedralCell 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 UseGeneral 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 UseGeneral 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 FieldsCell 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 UseSets, 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 UseSets, 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 FieldsParallel 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)