►Coreform Cubit™ Reference Manual
▼7 The Finite Element Model
►7.2 Exodus
On this page:
7.2.1 Element Block Specification
7.2.2 Exodus II File Specification
7.2.3 Exodus II Model Title
7.2.4 Exodus Coordinate Frames
7.2.5 Defining Materials and Media Types
7.2.6 Exodus Boundary Conditions and Element Types
7.2.7 Nodeset and Sideset Specification
2021.10
  top  contents  ← prev  up  next → 

7.2 Exodus

7.2.1 Element Block Specification

Element blocks are the method CUBIT uses to group related sets of elements into a single entity. Each element in an element block must have the same basic and specific element type. The preferred method for defining blocks is to use geometric entities such as volumes, surfaces or curves. Blocks can also be defined using mesh entities. If a block is defined at a geometric entity, each of the elements owned by the geometry are automatically assigned to the block. Deleting or remeshing the geometry automatically changes the set of elements grouped into the block. If mesh entities are used to specify a block, deleting the mesh will also delete the elements from the block. Some important notes regarding Element Blocks are as follows:

7.2.1.1 Creating Element Blocks

Element blocks are defined with the following Block commands.

block <block_id> [ADD|remove] {vertex | node} <range>

These commands define blocks based on a list of geometric or mesh entities. A block can only hold entities of the same dimensionality. For example, a block defined to hold vertices and nodes cannot also hold hexes. The above commands reflect this restriction. This restriction also applies when adding entities using groups. When creating a block using a group containing entities of different dimensionality the behavior is undefined. Adding geometric entities to a block effectivily adds all mesh entities of the same dimensionality contained in the geometric entity to the block. For example, adding a volume to a block adds all hexes, tets, pyramids and wedges contained in the volume to the block. Removing geometry entities works in the same manner. Thus the following commands:

block 1 add volume 1

Creates block 1 containing all of the hexes, tets, pyramids and wedges in volume 1 except for hex 1. When a mesh entity, or a meshed geometric entity is put into a block, it is assigned a global element ID which is exported to the exodus file for tracking during analysis.

7.2.1.2 Assigning a Name or Description to an Element Block

The following commands can be used to assign a name or description to an element block. Assigning a name to a block can be more intuitive than using traditional integer IDs, and the name and description are preserved in DART metadata-enabled applications (like SIMBA). This command is also available for nodesets and sidesets.

block<ids> name "<new_name>"

7.2.1.3 Defining the Element Type

Each block must have a specific element type associated with it. To assign an element type to a block, use the following command:

block <block_id_range> element type <type>

Available element types are defined by the Exodus II file format specification (Schoof, 95). CUBIT supports the following element types:

Nodes: SPHERE SPRING Curves: BAR BAR2 BAR3 BEAM BEAM2 BEAM3 TRUSS TRUSS2 TRUSS3 SPRING Surfaces: QUAD QUAD4 QUAD5 QUAD8 QUAD9 SHELL SHELL4 SHELL8 SHELL9 HEXSHELL TRI TRI3 TRI6 TRI7 TRISHELL TRISHELL3 TRISHELL6 TRISHELL7 Volumes: HEX HEX8 HEX9 HEX20 HEX27 TETRA TETRA4 TETRA8 TETRA10 TETRA14 TETRA15 PYRAMID PYRAMID5 PYRAMID13 PYRAMID18 WEDGE WEDGE6 WEDGE15 WEDGE16 WEDGE20 WEDGE21

If the element type is not assigned for an element block, it will be assigned a default type depending on which type of geometry entity is contained in the block. The default values used for element type are:

Volume: 8-node hexahedral elements (HEX8) will be generated for hex meshes. TETRA4 will be generated for tet meshes. Surface: 4-node shell elements (SHELL4) will be generated for quad meshes and TRISHELL3 for tri meshes. Curve: 2-node bar elements (BAR2) will be generated. Node: 1-node elements (SPHERE) will be generated.

7.2.1.4 Node Constraints for High Order Elements

Higher order nodes are moved to curved geometry by default. To change this, use the following command:

set node constraint [on|off|SMART][tet quality [distortion|NORMALIZED INRADIUS]][threshold <value=0.15>]

on means higher order mid-nodes snap to curved geometry. off means the mid-nodes retain their positions. smart means higher order mid-nodes will only snap to geometry if they do not cause quality problems after being moved. Nodes that cannot be moved without causing quality problems are placed at the average location of the element nodes: for edges, this means on the line containing the edge; for 2d elements, this usually means on the plane containing the element. When the smart option is used, the tet quality and threshold options can also be used. tet quality indicates the quality metric that will be used for determining whether mid-nodes will be projected or straightened. This option is currently only valid for high order tets (TETRA10) and tris (TRI6). normalized inradius or distortion metrics may be selected as criteria for projections. The threshold value indicates the quality value at which mid-nodes will not be projected. For example, if normalized inradius falls below the threshold value, the element edge will be straightened. Those with metrics above the threshold will be projected.

7.2.1.5 Default Element Blocks

When exporting an ExodusII file, if the user has not specified any Element Blocks, by default element blocks will be written for any meshed volumes. This default behavior can be changed, to write surface, volume, or no meshes by default. This option can be set using the command

set default block [ON|off|volume|surface|curve]

Default behavior, ON, is for the blocks to automatically be written based on their owning geometry. When the OFF setting is used, only the mesh contained in blocks created by the user will be exported. Mesh not in an element block at export time, will not be exported. The export will still succeed and no error will be thrown. If volume is specified, only elements contained in volumes will have default blocks specified. Similarly, the surface or curve argument indicates that only surfaces or curves containing elements will use default blocks, respectively. When default blocks are used, the IDs for the resulting blocks will be the ID of the owning geometry.

7.2.1.6 Duplicate Block Elements

By default, any given element cannot be included in more than one block. However, when using the following command, an element may be included in more than one block. Please note, since material properties are assigned to blocks, using this command to allow duplicate block elements may result in an element being assigned to multiple materials.

set duplicate block elements {on|off}

Cubit stores only a single Global Element ID (GID) for each element. If an element is placed into more than one block, when the model is exported to Exodus, new additional GIDs will be assigned to the element for each additional block that an element is in. These additional GIDs are exported to the exodus file, but Cubit currently only stores and tracks the first GID assigned.

7.2.1.7 Assigning Attributes to Blocks

It may be necessary to associate attributes with a specific element block. Attributes are generally integer or floating point values that represent some physical property in the region occupied by the block, such as material properties or shell thickness. To assign the number of attributes for an element block, use the following command:

block <id_range> attribute count <0-20>

CUBIT will store up to 20 attributes per block. Specify the maximum number of attributes to be stored on the block with this command. Once this command has been executed, individual attributes may be set using the following command:

block <id_range> attribute index <index> <value>

The index is an integer from 1 to the maximum count specified in the Block Attribute Count command. The value may be any valid floating point number. To assign a value to all attributes of an element block, use the command:

block <block_id_range> attribute <value>

7.2.1.8 Displaying Element Blocks

Blocks can be viewed individually with CUBIT by employing the following command:

draw block <block_id_range> [color <color_spec>] [add] [thickness [offset [scale <val>] | include_normal]]

For blocks that are of type SHELL and TRISHELL or one of its variants including the [thickness] keyword and parameters will result in the blocks being color-coded by shell thickness with a corresponding color bar. Blocks can be drawn with their specified thickness, so they visually have a thickness. This thickness can also be scaled in the draw command. Arrows defining the shell normal direction will be displayed as well as a legend showing the thickness values. Block colors can also be changed using the following command:

color block <block_id_range> {color|Default}

7.2.1.9 Deleting Element Blocks

All Nodesets, Sidesets and Blocks may be deleted from the model using the following command:

reset genesis

To remove only Blocks, the following may be used:

reset block

To remove a specific block, use:

delete block <block_id_range>

7.2.1.10 Renumbering Element Blocks

The block renumber command gives the user the ability to renumber blocks to fit the user’s needs. The command is:

Block <id_range> renumber start_id <id> [uniqueids]

The id_range must include existing entities or the command will fail. The start_id plus the number of entities must specify a new id space that does not overlap with the existing block ids. In other words, if the current block numbers are 100, 105, 106, and 109, a start_id of 102 would suggest new block numbers of 102, 103, 104, and 105. This would cause an id space conflict and the command will fail. If the user specifies the uniqueids option, then the new entity id space must not conflict with the existing id space of all blocks, nodesets, and sidesets. Example: Assume:

block ids: 100, 105, 106, 109 block all renumber start 20 block 20 renumber start 24

After commands:

block ids: 21, 22, 23, 24

To renumber the elements within a block, see the renumber command

7.2.1.11  Automatically Assigning Mesh Edges to a Block (Rebar)

After a mesh has been defined within a volume, it may be useful to use the existing mesh edges as the basis for an element block. Such an element block might be composed of bars or truss type elements that might propagate through a solid medium such as rebar placed in reinforced concrete. Although the block <id> edge <range> command could be used for this task, it would prove extremely tedious defining the individual edges to add to the block. To make this process easier, the following command can be used:

rebar start <x> <y> <z> direction <x> <y> <z> [length <value>] block <id> [element type {bar|bar2|bar3|BEAM|beam2|beam3|truss|truss2|truss3}]

The rebar command allows the user to specify a starting location for a set of edges and an initial direction. The program will find the closest existing node in the mesh to start <x> <y> <z> and begin propagating through the mesh in the specified direction <x> <y> <z>, adding edges to the block as it propagates through the mesh. The edge that is attached to the last node and is within a fixed 30 degrees of the specified direction is added to the block. The Propagation of the edges continues until either the optional length value is reached or an edge does not meet the direction criteria. Also required with this command is a block ID. An element type can also be specified. Similarly, you can use the following command which will use the 30 degree cone described above to gather edges from a surface into a single block using the Cartesian x, y, and/or z vectors.

rebar surface <range> [x] [y] [z] block <id> [element type {bar|bar2|bar3|BEAM|beam2|beam3|truss|truss2|truss3}] [Propagate]

7.2.1.11.1 Diagonal and Orthogonal Rebar Blocks

Another method for generating rebar blocks include the Diagonal/Orthogonal option. This command can only be used on surfaces that have been meshed with the mapping scheme. This command will create a block of edges from the mapped mesh by starting in one corner and gathering edges orthogonally, or creating new edges diagonally based on the option specified, using the parametric coordinate system dictated by the mapping scheme on the surface. The spacing option dictates how many edges are skipped over before starting the next set of rebar edges.

rebar surface <range> {diagonal|orthogonal} [Spacing <int>] [Block <id> [Element Type {bar|bar2|bar3|BEAM|beam2|beam3|truss}]

7.2.1.11.2 Specifying a set of nodes

A final rebar option allows the user to create or group rebar edges into a specified block using nodes. Edges are created, or gathered, using the ordered list of nodes specified in the command.

rebar node <range> [target block <id>] [element type {bar|bar2|bar3|BEAM|beam2|beam3|truss}]

Figure 474

CUBIT> rebar node 113 105 97 89 81 73 65 57 49 target block 1

A related command for creating curve geometry directly from mesh edges is the Create Curve from Mesh command. See Curve creation for more details.

7.2.1.12 Creating Spider Blocks

The block creation tool also allows the user to create a special block of bar elements that can be used as part of the boundary specification. This command creates beam type elements directly without creating any underlying geometry. The command for creating this type of block is:

block <id> joint [vertex <id> | node <id> ] spider {surface|curve|vertexface|tri|node} <range> [preview] [element type {bar|bar2|bar3|BEAM|beam2|beam3|truss|truss2|truss3}]

The joint node is the starting location of the bar elements and the spider location is the terminating location of the bar elements.You can specify the joint node as either a node or a vertex. Optionally, if no joint node is specified, a joint node will automatically be created at the centroid of the nodes on the specified terminating location. You can specify the terminating location as either a node, vertex, geometric surface or the face of a mesh entity. Some analysis codes refer to these bar elements as tied contacts or rigid bar elements.They can be used to tie models together or to enforce specific kinds of boundary conditions.For example, in the figure below a block of beam elements is used to tie a node at the center of the circle to every node on the edge of the circle.This arrangement can be used to enforce circularity but still allow for displacement of the entire circle. This may occur if there are additional structures above the cylinder that are being excluded from the current finite element model.The beam elements were created by a series of commands of the form

block 10 joint node 1 spider node 2

The preview option can be included to draw the location of the beam blocks on the screen without actually executing the command. When specifying vertex ids, please know the bar elements will be tied to the nodes associated with the vertex, not the vertex itself.

Figure 475: beam elements created with the spider command

7.2.1.13 Creating Beam Blocks

Properties for blocks that are beam types (beam, beam2, beam3) have additional commands to define a cross-sectional area. The following command can be used to change the type of cross-sectional area of a beam block:

Block <id> beam_type {CIRCLE|box|rectangle|pipe|ibeam|general}

The dimensions are set by listing them after the keyword beam_dimensions:

Block <id> beam_dimensions <values>

The order in which the values need to be specified are described in the chart below. If the solver used is to integrate over the section during the simulation, turn section_integration on using the following command:

block <id> section_integration {ON|off}

The beam normal vector is a vector normal to the plane of motion and tangent to the first bending axis. This vector can be set using the following command:

Block <id> beam_normal <x><y><z>

Section Profile

Order to Specify Dimensions

Circle

Radius

Pipe

Outer radius, wall thickness

Rectangle

Width, height

Box

Total width, total height, thickness (right), thickness (top), thickness (left), thickness (bottom)

I-Beam

Distance to bending axis (from bottom), total height, bottom width, top width, thickness (bottom), thickness (top), thickness (web)

General

Area, Ixx, Ixy, Iyy, Polar moment of inertia (J)

7.2.1.14 Creating Spring Blocks

Spring blocks that will be exported to Abaqus can contain additional properties related to Abaqus springs. Users can specify the spring type, stiffness, and DOFs associated with Abaqus springs. The spring type mapping to Abaqus elements is in the following table.

CUBIT Block Spring Type

Abaqus Element Type

Node_to_node

SPRINGA

Node_to_node

SPRING1

Node_to_ground_fixed

SPRING2

The spring type is set using the spring_type keyword. In order to use this command, the block must already have an element type of "SPRING." If a DOF is associated with a spring, the spring_dof_1 keyword is used to specify the DOF on the first node and spring_dof_2 is used to specify the DOF on the second node (SPRING2 only).

Block <id> [spring_type {NODE_TO_NODE | node_to_node_fixed_axis | node_to_ground}] [stiffness <k>] [spring_dof_1 <n>] [spring_dof_2 <n>]

7.2.1.15 Creating Sphere Blocks

Sphere elements are created in CUBIT by inserting either nodes or vertices into a block.

Block <id> {node|vertex} <id_range>

The command above causes CUBIT to internally create a sphere element and associate it to the inserted node, or to the node associated to the inserted vertex.

example:

brick x 10
vol all size 5
mesh vol all
create vertex 0 0 10
#{sph_vtx_id=id("vertex")}
mesh vertex {sph_vtx_id}
#{sph_nd=id("node")}
block 1 volume 1
block 2 vertex {sph_vtx_id}
block 3 joint node {sph_nd} spider surf 1
locate sphere all

The example commands above will generate the model illustrated in the figure below.

Figure 476: A sphere element created and connected to a solid mesh with 2d elements.

You can interact with sphere elements in Cubit with the commands below:

locate sphere <id_range> draw sphere <id_range> highlight sphere <id_range> list sphere ids list sphere <id_range>

7.2.1.16 2D Elements

CUBIT is a 3d mesh generator by default. Element types, by default, are respectively TRISHELL and SHELL for triangle and quad elements. If a 2d mesh is desired, blocks types must be explicitly set to TRI or QUAD.

Example:

create brick x 10
surface 1 scheme trimesh
mesh surface 1
block 1 surface 1
block 1 element type tri
export mesh "mymesh.exo"

sideset 1 will be based on the TRI and QUAD elements in blocks 1 and 2, with the side numbering referring to the edges of the triangles and quads.

7.2.1.17 Mixed Element Output

The set block mixed output command controls the behavior of blocks containing different element types when exporting in a file format that doesn’t support blocks with mixed element types. If DEGENERATE, all elements will be exported in one block, but tets and pyramids will be written as degenerate hexes, and triangles will be written as degenerate quads. If OFFset(set by default), then new element blocks will be created separating the types. Hex and Quad blocks retain the block id, whereas tets, triangle, pyramids and wedges get put into other blocks. The ids of the other blocks are based on the block id plus the offset for that type. Those values are set using the offset commands.

set block mixed element output { OFFSET | degenerate }

7.2.1.18 Adding Materials to a Block

block <id> material <id|’name’>

If a material is assigned to an element block, the material properties will be associated with the block’s elements when the mesh is exported. If no material is assigned to a block, a default material will be used during export.

7.2.1.19 SUPERELEMENT_TOPOLOGY_XX Support

Lite import of Exodus files with elements of SUPERELEMENT_TOPOLOGY_XX. What’s currently supported:

What’s currently NOT supported:

7.2.2 Exodus II File Specification

7.2.2.1 Exodus II Manual

The full https://github.com/gsjaardema/seacas#exodus is available from the web.

7.2.2.2 Element Block Definition Examples
7.2.2.2.1 Multiple Element Blocks

Multiple element blocks are often used when generating a finite element mesh. For example, if the finite element model consists of a block which has a thin shell encasing the volume mesh, the following block commands would be used:

block 100 volume 1
Block 100 Element Type Hex8
Block 200 Surface 1 To 6
Block 200 Element Type Shell4
Block 200 Attribute 0.01
Mesh Volume 1
Export Genesis ‘block.g’

This sequence of commands defines two element blocks (100 and 200). Element block 100 is composed of 8-node hexahedral elements and element block 200 is composed of 4-node shell elements on the surface of the block. The "thickness" of the shell elements is 0.01. The finite element code which reads the Genesis file (block.g) would refer to these blocks using the element block IDs 100 and 200. Note that the second line and the fourth line of the example are not required since both commands represent the default element type for the respective element blocks.

7.2.2.2.2 Surface Mesh Only

If a mesh containing only the surface of the block is desired, the first two lines of the example would be omitted and the Mesh Volume 1 line would be changed to, for example

mesh surface 1 to 6

7.2.2.2.3 Two-dimensional Mesh

Cubit also provides the capability of writing two-dimensional Genesis databases similar to FASTQ. The user must first assign the appropriate surfaces in the model to an element block. Then a Quad* type element may be specified for the element block. For example

block 1 surface 1 to 4
block 1 element type quad4

In this case, it is important for users to note that a two-dimensional Genesis database will result. In writing a two-dimensional Genesis database, Cubit ignores all z-coordinate data. Therefore, the user must ensure that the Element Block is assigned to a planar surface lying in a plane parallel to the x-y plane. Currently, the Quad* element types are the only supported two-dimensional elements. Two-dimensional shell elements will be added in the near future if required.

7.2.3 Exodus II Model Title

 

Cubit will automatically generate a default title for the Genesis database. The default title has the form: Cubit(genesis_filename): date: time

The title can be changed using the command: Title ’<title_string>’

 

7.2.4 Exodus Coordinate Frames

Cubit allows the user to define coordinate systems (frames) that are written to an Exodus II file. These coordinate frames are generally used as reference coordinate systems during analysis. In Cubit, the user may define multiple exodus coordinate frames. When created, a coordinate frame is assigned an id. Exodus coordinate frames can be created using x-y-z coordinates, nodes or vertices with the following commands:

Exodus Create Coordinate Frame
<xval> <yval> <zval>//origin
<xval> <yval> <zval> //z-axis
<xval> <yval> <zval> //xz-plane
[tag { ’R’ | ’C’ | ’S’ } ]

Using the ’tag’ option specifies the type of coordinate frame, i.e., rectangular (R), cylindrical (C) or spherical (S). The default coordinate frame type is rectangular. Exodus coordinate frames may also be listed and deleted using the commands below:

List Exodus Coordinate Frame [ids] [ <frame_id>]

Any exodus coordinate frames that exist at the time the exodus file is exported will be written out in the exodus file.  

7.2.5 Defining Materials and Media Types

Materials can be defined in CUBIT and assigned to element blocks. If an element block is exported without a material assigned to it, a default material (with properties for common steel) will be exported for it.

create material [id] [name <’name’>] [elastic_modulus <value>] [poisson_ratio <value>] [shear_modulus <value>] [density <value>] [specific_heat <value>] [conductivity <value>] [user constants <value ...>] [depvar <value>]

Materials can be created with any number of the following material properties:

Media types include:

Any properties that are not initialized by the user will have a default value of 0. Materials and media types can be listed and deleted using the following commands:

list material <id_list|’name’|all>

Materials and media can be added to an existing block using the following command:

Block <id> Material <id|’name’> Block <id> Media <id|’name’>

7.2.5.1 Custom Material Commands

The Cubit/Cubit SDK allows custom material properties to be defined using the MaterialInterface. The following versions of the material commands allow users to create materials with custom properties that have already been defined using the SDK.

Create {material|media} ’material_name’ property_group ’group_name’ [id <requested_id>] [description ’string’] Modify {material|media} ’material_name’ [property_group ’group_name’] [id <requested_id>] [description ’string’] [rename ’new_name’]
[scalar_properties (’property_name’ <property_value>)...]
[vector_property ’property_name’ <val1> <val2>...]
[matrix_property ’property_name’ <val1> <val2>...]
[clear properties ’property_name1’ ’property_name2’...]

A scalar property has a single value associated with it. The scalar properties defined by Cubit are:

Vector properties are given in the command as a list of values. The vector properties defined in Cubit/Cubit are:

Matrix properties are also given as a list of values. The number of columns in the matrix is defined by the specific property, and Cubit automatically divides the given values into rows and columns based on the column count. For example, if a matrix property has 2 columns, the value list "2 33.1 3 18.9" is interpreted as the matrix:

2

   

33.1

3

   

18.9


Cubit/Cubit defines the following matrix properties:

A property group is a collection of material properties. Its main purpose is to help define what properties a material should have, even if a value is not given for the property. Cubit/Cubit defines the following property groups:

Table 1. Property groups defined in CUBIT

Property

   

cubit-fea

   

cubit-abaqus

   

cubit-cfd

cfd_media_type

   

   

   

x

modulus

   

x

   

x

   

shear_modulus

   

x

   

x

   

poisson

   

x

   

x

   

density

   

x

   

x

   

specific_heat

   

x

   

x

   

conductivity

   

x

   

x

   

thermal_expansion

   

x

   

x

   

yield_strength

   

x

   

x

   

ultimate_strength

   

x

   

x

   

ultimate_strain

   

x

   

x

   

depvar

   

   

x

   

user_constants

   

x

   

x

   

elastic_modulus_vs_temperature

   

   

x

   

poissons_ratio_vs_temperature

   

   

x

   

density_vs_temperature

   

   

x

   

yield_stress_vs_strain_vs_temperature

   

   

x

   

specific_heat_vs_temperature

   

   

x

   

conductivity_vs_temperature

   

   

x

   

7.2.6 Exodus Boundary Conditions and Element Types

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.

7.2.6.1 Element Blocks

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.

7.2.6.2 Nodesets

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.

7.2.6.3 Sidesets

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.

7.2.6.4 Element Types

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. 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. Higher-order nodes are created only when the mesh is being exported to the Exodus II file, and persist in the Cubit database after file export.

Table 1. Element Types Defined in Cubit

Basic Element Type

Specific Element Type

Notes

Edge

BAR, BEAM

Bars have 2 DOF’s per node, Beams 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

Quad element nodal coordinates are 2D, that is their nodes contain only x and y coordinates. Shell element nodal coordinates are 3D.

Tetrahedron

TETRA, TETRA4, TETRA8, TETRA10

TETRA8 contains vertex nodes and mid-face nodes, experimental element used in Sandia FEA research

Hexahedron

HEX, HEX8, HEX20, HEX27

 

 

7.2.7 Nodeset and Sideset Specification

Boundary conditions such as constraints and loads are applied to the finite element model using nodesets or sidesets, also known as Genesis entities. Rather than attempting to maintain specific boundary condition information, such as load, temperature, constraint, etc., Genesis entities are the generic vehicle for the user to set up boundary conditions on the model. Nodes, elements and element faces are instead grouped together and assigned unique IDs. Node, element and face IDs assigned to Genesis entities can then be written to the Exodus II mesh file. Once imported to the intended analysis application, the nodeset and sideset IDs can be appropriately interpreted as specific physical boundary conditions. The preferred method for creating Genesis entities is to assign vertices, curves, surfaces or volumes to a specific nodeset or sideset ID. Any mesh entity owned by the geometric entity in a nodeset or sideset is automatically assigned to the same nodeset or sideset. This allows greatest flexibility in generating and updating the finite element mesh. For example, if a surface belongs to a specific sideset, remeshing the surface will automatically delete any old faces from the sideset and add the faces of the new mesh. In some cases, the geometric model does not provide enough resolution to define the desired boundary conditions. In this case, the model may be partitioned using Cubit’s virtual geometry features. Where this may not be feasible, mesh entities can also be added directly to the desired nodeset or sideset. Where individual mesh entities have been added to nodesets or sidesets, deleting the mesh will also remove these elements from the Genesis entity. If the geometry is remeshed, the new mesh entities must also be added once again to the nodesets or sidesets. Nodesets can be created from groups of nodes categorized by their owning volumes, surfaces, curves or vertex. Individual nodes may also be added to a nodeset. Nodes can belong to more than one nodeset. Sidesets can be created from groups of element sides or faces categorized by their owning surfaces or curves or by their individual face IDs. Element sides and faces can also belong to more than one sideset.

7.2.7.1 Creating Nodesets and Sidesets

Nodesets and Sidesets are created in Cubit by assigning the appropriate geometry or mesh entities in the model to a nodeset or sideset ID. The following commands can be used:

nodeset <nodeset_id> [ADD|remove] {curve | surface | volume | vertex | node} <range>

Sideset <sideset_id> [ADD|Remove] Group <id_range>

}

Sideset <sideset_id> [ADD|Remove] {Curve|Surface|Edge|Face|Tri} <id_range>

}

Sideset <sideset_id> [Add] Edge <id_range> [wrt {{Tri|Face} <id_range> | all } ]

}

Sideset <sideset_id> [Add] Face <id_range> [wrt {Hex <id_range> | all} ]

}

Sideset <sideset_id> [Add] Tri <id_range> [wrt {Tet <id_range> | all} ]

}

Sideset <sideset_id> [Add] Surface <id_range> [wrt {{Volume|Surface} <id_range> | all} ] [FORWARD|Reverse|Both]

}

Sideset <sideset_id> [Add] Curve <id_range> [wrt {Surface <id_range> | all} ]

}

Like element blocks, Nodesets and Sidesets are given arbitrary, user-defined ID numbers. If there are no user-defined Nodesets or Sidesets, none are written to the Exodus II file. With Sidesets, direction is often important. For surfaces, the direction may be specified using the forward, reverse, or both options. The forward option will write a sideset in relation to hexes in the surface’s forward volume, which is the volume that the surface’s normal points away from. The reverse option will write a sideset in relation to hexes in the surface’s reverse volume, which is the volume that the surface’s normal points into. The both option will allow sidesets to be written in relation to the hexes that lie in volumes on both sides of the surface. The default is forward. The user can additionally specify the volume from which the hexes should be taken in relation to by using the wrt volume option. Direction is equally important for curves in Sidesets. The wrt surface option allows the user to indicate which surface’s faces will be included in the Sideset. The wrt all option will include all faces attached to the curve. The default is wrt All.

7.2.7.1.1 Useful hint:

When creating nodesets and sidesets it is often useful to use the Extended Command Line Entity Specification. Here is an example that creates a nodeset which includes all the nodes on the exterior of the geometry:

# create the geometry Create brick x 10 Create cylinder height 10 radius 2 Move volume 2 z 10 # Merge the geometry Merge volume all # Mesh the geometry Mesh volume all # Create a nodeset that includes only those nodes # located on the exterior of the geometry Nodeset 1 add surface in volume all with not is_merged

The following commands remove nodes from the nodeset that belong to a surface. Continuing from the previous example:

# remove surface 2 from the nodeset Nodeset 1 remove surface 2 # Remove nodes from the nodeset # that belong to the curves that bound surface 2 Nodeset 1 remove node in curve in surface 2

Nodes can also be added or removed based upon their coordinates. Here is an example that removes all the nodes with a z coordinate equal to 15. Continuing from the previous example:

# remove the nodes with a z coordinate equal to 15 Nodeset 1 remove node in surface all with z_coord = 15

7.2.7.2 Assigning Names and Descriptions to Nodesets and Sidesets

Nodesets and sidesets can be assigned names and descriptions. Using names and descriptions is often more intuitive than using traditional integer IDs. When exporting a mesh as a DART artifact, names and descriptions are included in the metadata, making them available to DART metadata-enabled applications such as SIMBA. To give a name or description to nodeset or sideset, use one of the following commands:

{nodeset|sideset} <ids> name "<new_name>"

This command can also be used to define names and descriptions for Element Blocks.

7.2.7.3 Grouping Faces on a Surface into a Sideset

A sideset can be created from a subset of the faces on a given surface by using one of the following commands:

sideset <sideset_id> surface <id_range> patch maximum <x> <y> <z> minimum <x> <y> <z>

SideSet <sideset_id> Surface <id_range> Patch Center <x> <y> <z> Radius <value> [Filter] [Partition]

}

SideSet <sideset_id> Surface <id_range> Patch Center <x> <y> <z> Outer_radius <value> inner_radius <value> [Filter] [Partition]

}

SideSet <sideset_id> Surface <id_range> Patch Cylinder <axis_specification> Radius <rad> [Filter] [Partition]

}

SideSet <sideset_id> Surface <id_range> Patch Cylinder <axis_specification> Outer_radius <rad> inner_radius <rad> [Filter] [Partition]

}

These commands place only the faces meeting the specified criteria into the sideset.

Normally, these commands place the individual elements into the sideset. If the mesh on the surface is deleted, the elements will be removed from the sideset. If the surface is then remeshed, new elements will NOT automatically be added to the sideset. This is usually the intended behavior. If the filter option is included, only a single connected set of elements is added to the sideset. If the shape of the surface is such that multiple disconnected sets of elements fall within the specified spherical or cylindrical region, the filter option will limit the faces added to the sideset to the one set closest to center. Using the partition option changes this behavior. The partition option causes the surface to be split, based on the faces included in the patch. The newly created patch surface will be added to the sideset instead of the individual elements. If the mesh is deleted and a new mesh is generated, the new mesh on the patch surface will automatically be included in the sideset, just as occurs with other geometric entities assigned to sidesets. Note that the sideset patch commands work with both triangular and quadrilateral faces.

7.2.7.3.1 Grouping elements in voids and enclosures

The sideset start enclosure command creates sidesets of monotonically increasing ID numbers containing the elements comprising the watertight skin of the input elements. When there’s a ’void’ in the middle of the elements, a region devoid of elements, though still enclosed by elements, this enclosed region will also have a sideset defined on the skin of the enclosed region.

sideset start <id> enclosure {volume|hex|tet} <range>

The start id is the id of the sideset at which to start. The ID numbers will increase monotonically unless there is a conflicting ID number. The command will add as many sidesets as there are fully continuous regions or tris or faces in the input group. This function can be particularly helpful for calculations for radiation enclosures.

7.2.7.4 Deleting Nodesets and Sidesets

All Nodesets, Sidesets and Blocks may be deleted from the model using the following command:

reset genesis

To remove only nodesets or sidesets, the following may be used:

reset nodeset

reset sideset

To remove a specific nodeset or sideset, use:

delete nodeset <nodeset_id_range>

7.2.7.5 Renumbering Nodesets and Sidesets

The nodeset and sideset renumber commands give the user the ability to renumber these entities to fit the user’s needs. The command is:

{Nodeset|Sideset} <id_range> renumber start_id <id> [uniqueids]

The id_range must include existing entities or the command will fail. The start_id plus the number of entities must specify a new id space that does not overlap with the existing id space for the entity. In other words, if the current sideset ids are 100, 105, 106, and 109, a start_id of 102 would suggest new sideset ids of 102, 103, 104, and 105. This would cause an id space conflict and the command will fail. If the user specifies the uniqueids option, then the new entity id space must not conflict with the existing id space of all blocks, nodesets, and sidesets.

Example: Assuming initial sideset IDs of (1, 2, 4, 6, 10), the command sideset all renumber start 30 will yield the renumbered sideset IDs (30, 31, 32, 33, 34).

7.2.7.6 Displaying Nodesets and Sidesets

Nodesets and Sidesets can be viewed individually through Cubit by employing the following commands:

draw nodeset <nodeset_id_range> [color <color_spec>] [add]

draw sideset <sideset_id_range> [Color <color_spec>] [add]

Nodeset and Sideset colors can also be changed using the following commands:

color nodeset <nodeset_id_range> {color|Default}

color sideset <sideset_id_range> {color|Default}

7.2.7.7 Nodeset Associativity Data

Nodesets can be used to store geometry associativity data in the Exodus II file. This data can be used to associate the corresponding mesh to an existing geometry in a subsequent Cubit session. This functionality can be used either to associate a previously-generated mesh with a geometry (See Importing an Exodus II File), or to associate a field function with a geometry for adaptive surface meshing (See Adaptive Meshing). The commands to control and list whether associativity data is written or read from an Exodus II files are the following:

list import mesh nodeset associativity list [export mesh] NodeSet Associativity list [export mesh] NodeSet Associativity Complete set import mesh NodeSet Associativity [ON|off] [set] [export mesh] NodeSet Associativity [on|OFF] [set] [export mesh] NodeSet Associativity Complete [On|OFF]

Associativity data is stored in the Exodus II file in two locations. First, a nodeset is written for each piece of geometry (vertices, curves, etc) containing the nodes owned for that geometry. Then, the name of each geometry entity is associated with the corresponding nodeset by writing a property name and designating the corresponding nodeset as having that property. Nodeset numbers used for associativity nodesets are determined by adding a fixed base number (depending on the order of the geometric entity) to the geometric entity id number. The base numbers for various orders of geometric entities are shown in the following table. For example, nodes owned by curve number 26 would be stored in associativity nodeset 40026.

Nodeset ID base numbers for geometric entities

Geometric Entity

   

Base Nodeset ID

Vertex

   

50000

Curve

   

40000

Surface

   

30000

Volume

   

20000

Instead of storing just the nodes owned by a particular entity, nodes for lower order entities are also stored. For example, the associativity nodeset for a surface would contain all nodes owned by that surface as well as the nodes on the bounding curves and vertices.

7.2.7.8 Equation-Controlled Distribution Factors

By default, distribution factors on nodesets or sidesets are written with a constant value of "1" at each node. It is also possible to vary the distribution factor for each node in a nodeset or sideset, using an equation to control the value of the distribution factor at each node. To do so, an equation must first be defined using the command:

create equation "<expression>" name "<name>"

where expression is any mathematical expression which evaluates to a single number, and name is the name by which this equation will be known. The expression is written using aprepro syntax, with a few differences from the use of APREPRO in its usual context.

  1. The expression as a whole is not wrapped in curly braces "{" and"}".

  2. The expression may include any of the following pre-defined variables:

x - The x-coordinate of the current node

y - The y-coordinate of the current node

z - The z-coordinate of the current node

n - The CUBIT ID of the current node. This is the ID of the node in Cubit, which may not be the same as the node’s ID in the Exodus II file.

For example, to define an equation which varies from -10 to 10 based on the sine of the node’s x_coordinate:

create equation "10*sin({x)" name "my_equation"}

Once an equation has been defined, it can be applied to a nodeset or sideset:

{nodeset|sideset} <id> Distribution Equation "<equation_name>"

For example, to apply the equation created earlier to nodeset 10:

nodeset 10 distribution equation "my_equation"

When nodeset 10 is written to an Exodus II file, "my_equation" will be evaluated once for each node in the nodeset, with the values of {x}, {y}, {z}, and {n} set to appropriate values for the node. The result is used as the distribution factor for that node. Here is a complete example that writes out the distribution factors 0.0, 0.5, and 1.0 for the 3 nodes on the curve:

# create a straight line from (0,0,0) to (1,0,0) create vertex 0 0 0 create vertex 1 0 0 create curve vertex 1 2 # Mesh with 3 nodes curve 1 interval 2 mesh curve 1 # Create a block and a nodeset block 1 curve 1 nodeset 1 curve 1 # Define an equation and apply it to the nodeset create equation "{x}" name "simple_eq" nodeset 1 distribution equation "simple_eq" # Write the mesh export mesh "temp.g" overwrite

Here is another complete example that varies the distribution factors for sideset 20 from zero to 1, depending on the node’s x-coordinate. The sideset is applied to sides of HEX20 elements, so each element side has 8 different distribution factors.

# mesh a cube brick x 10 mesh volume 1 # Create a block of 20-noded hexes block 1 volume 1 block 1 element type hex20 # Apply a sideset to be used for a variable pressure sideset 20 surface 1 # Define an equation and apply it to the sideset create equation "({x}+5)/10" name "zero_to_one" sideset 20 distribution equation "zero_to_one" # Write the mesh export mesh "temp.g" overwrite

Note that distribution equations only affect Exodus II output. Equations are currently ignored for other mesh file types. See APREPRO in the appendix.

7.2.7.9 Nodesets/Sidesets/Blocks Behavior with Geometric Entity Copy

The below commands can be used to set the behavior of nodesets/sidesets/blocks when a copy command is applied on geometric entities. The default OFF option specifies that any nodesets/sidesets/blocks on the original geometry will not be copied to the new geometry. The on option implies that for each nodeset/sideset/block present in the original geometric entity a corresponding nodeset/sideset/block with be present on the new geometric entity. The use_original option indicates that instead of creating new nodesets/sidesets/blocks on the new geometry, the new sideset/nodeset/block information will instead be added to the original nodesets/sidesets/blocks present in the original geometric entities.

set copy_nodeset_on_geometry_copy [on | OFF| use_original]

set copy_sideset_on_geometry_copy [on | OFF| use_original]

set copy_block_on_geometry_copy [on | OFF| use_original]

  top  contents  ← prev  up  next →