Cubit 16.10 User Documentation
Sandia's finite element analysis codes have been written to transfer mesh definition data in the ExodusII file format (citation Schoof, 95). The ExodusII database exported during a CUBIT session is sometimes referred to as a Genesis database file; this term is used to refer to a subset of an Exodus file containing the problem definition only, i.e., no analysis results are included in the database.
The ExodusII database contains mechanisms for grouping elements into Element Blocks, which are used to define material types of elements. ExodusII also allows the definition of groups of nodes and element sides in Nodesets and Sidesets, respectively; these are useful for defining boundary and initial conditions. Using Element Blocks, Nodesets and Sidesets allows the grouping of elements, nodes and sides for use in defining boundary conditions, without storing analysis code-specific boundary condition types. This allows CUBIT to generate meshes for many different types of finite element codes.
Element Blocks (also referred to as simply, Blocks) are a logical grouping of elements all having the same basic geometry and number of nodes. All elements within an Element Block are required to have the same element type. Access to an Element Block is accomplished through a user-specified integer Block ID. Typically, Element Blocks can also be assigned material properties to associate material properties with a group of elements.
Nodesets are a logical grouping of nodes accessed through a user-specified Nodeset ID. Nodesets provide a means to reference a group of nodes with a single ID. They are typically used to specify load or boundary conditions on portions of the CUBIT model or to identify a group of nodes for a special output request in the finite element analysis code.
Sidesets are another mechanism by which constraints may be applied to the model. Sidesets represent a grouping of element sides and are also referenced using an integer Sideset ID. They are typically used in situations where a constraint must be associated with element sides to satisfactorily represent the physics (for example, a contact surface or a pressure.
The basic elements used to discretize geometry were described in the mesh generation chapter. Within each basic element type, several specific element types are available. These specific element types vary by the number of nodes used to define the element, and result in different orders of accuracy of the element. The element types available for each basic element type defined in CUBIT are summarized in the following table.
Table 1. Element Types Defined in CUBIT
Basic Element Type
|
Specific Element Type
|
Notes
|
Node | SPHERE | |
Edge | BAR, BAR2, BAR3, BEAM, BEAM2, BEAM3, TRUSS, TRUSS2, TRUSS3, SPRING | By default, Bars have 2 DOF's per node; Beams, trusses and springs have 3 |
Triangle | TRI, TRI3, TRI6, TRI7, TRISHELL, TRISHELL3, TRISHELL6, TRISHELL7 | Tri element nodal coordinates are always 3D. |
Quadrilateral | QUAD, QUAD4, QUAD8, QUAD9; SHELL, SHELL4, SHELL8, SHELL9, HEXSHELL | By default, quad element nodal coordinates are 2D, i.e., only x and y coordinates. Shell element nodal coordinates are 3D. |
Tetrahedron | TETRA, TETRA4, TETRA8, TETRA10, TETRA14, TETRA15 | TETRA8 contains vertex nodes and mid-face nodes. |
Hexahedron | HEX, HEX8, HEX9, HEX20, HEX27 | |
Pyramid | PYRAMID, PYRAMID5, PYRAMID8, PYRAMID13, PYRAMID18 | A PYRAMID8 is output as a degenerate HEX. |
Wedge | WEDGE, WEDGE6, WEDGE15, WEDGE16, WEDGE20, WEDGE21 | |
Superelement | SUPERELEMENT_TOPOLOGY_XXX | An element composed of an variable number of nodes. |
For a description of the node and side numbering conventions for each specific element type, see the Appendix. Element types can be set for individual Element Blocks, either before or after meshing has been performed.