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:
Multiple volumes, surfaces, and curves can be contained in a single element block
A volume, surface, or curve can only be in one element block
Element Block id’s are arbitrary and user-defined. They do not need to be in any contiguous sequence of integers.
Element Blocks can be assigned a single floating point number, referred to as the block Attribute; this number is used to represent the length or thickness of Bar and Shell elements, respectively. The attribute defaults to 1.0 if not specified.
7.2.1.1 Creating Element Blocks
block <block_id> [ADD|remove] {vertex | node} <range>
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
block<ids> name "<new_name>"
7.2.1.3 Defining the Element Type
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
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
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
block <id_range> attribute count <0-20>
block <id_range> attribute index <index> <value>
block <block_id_range> attribute <value>
7.2.1.8 Displaying Element Blocks
draw block <block_id_range> [color <color_spec>] [add] [thickness [offset [scale <val>] | include_normal]]
color block <block_id_range> {color|Default}
7.2.1.9 Deleting Element Blocks
reset genesis
reset block
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)
rebar start <x> <y> <z> direction <x> <y> <z> [length <value>] block <id> [element type {bar|bar2|bar3|BEAM|beam2|beam3|truss|truss2|truss3}]
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
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
rebar node <range> [target block <id>] [element type {bar|bar2|bar3|BEAM|beam2|beam3|truss}]
CUBIT> rebar node 113 105 97 89 81 73 65 57 49 target block 1
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.
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>
block <id> section_integration {ON|off}
Block <id> beam_normal <x><y><z>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
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
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.
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
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:
Element type information displayed in property page and when listing blocks.
Export to Exodus file with type SUPERELEMENT_TOPOLOGY_XX
What’s currently NOT supported:
Visualization
import mesh geometry ’<exodusII_filename> ...’
import mesh ’<exodusII_filename> no_geom ...’
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
Exodus Create Coordinate Frame
<xval> <yval> <zval>//origin
<xval> <yval> <zval> //z-axis
<xval> <yval> <zval> //xz-plane
[tag { ’R’ | ’C’ | ’S’ } ]
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
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:
Elastic modulus
Poisson Ratio
Density
Specific Heat
Conductivity
Shear Modulus (must satisfy E = 2G(1+v) )
User Constants
DepVar (Only written to Abaqus file)
Media types include:
Fluid
Porous
Solid
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’...]
modulus (The modulus of elasticity)
shear_modulus
poisson (Poisson’s ratio)
density
specific_heat
conductivity (Thermal conductivity, not electrical)
thermal_expansion
yield_strength
ultimate_strength
ultimate_strain
depvar (Property required for Abaqus export)
cfd_media_type (0 = fluid; 1 = porous; 2 = solid)
Vector properties are given in the command as a list of values. The vector properties defined in Cubit/Cubit are:
user_constants (User-defined material constants)
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:
elastic_modulus_vs_temperature (2 columns)
poissons_ratio_vs_temperature (2 columns)
density_vs_temperature (2 columns)
yield_stress_vs_strain_vs_temperature (3 columns)
specific_heat_vs_temperature (2 columns)
conductivity_vs_temperature (2 columns)
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:
cubit-fea (generic FEA material)
cubit-abaqus (material specific to Abaqus export)
cubit-cfd (generic CFD media)
|
|
|
|
|
|
|
|
|
|
|
| ||
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
| ||
|
|
|
|
|
| |
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
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:
# 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
# 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
# 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
{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
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.
Using the maximum and minimum options will include all faces on the surface whose centroid falls within the axis-aligned box defined by the maximum and minimum points.
Using the center and radius options will include all faces on the surface whose centroid falls within the sphere defined by center and radius.
Using the center, outer_radius, and inner_radius options will include all faces on the surface whose centroid falls within the sphere defined by center and outer_radius, but excluding those faces whose centroid falls within the sphere defined by center and inner_radius. In other words, a face will be included if the distance between the face and the center point is between inner_radius and outer_radius.
Using the cylinder option will include all faces whose centroid falls within a cylinder of infinite length with the given axis and radius. The axis is specified as described in Specifying an Axis.
Using the optional inner_radius will exclude those faces whose centroid is closer to the axis than the specified inner_radius.
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
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
reset genesis
reset nodeset
reset sideset
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
draw nodeset <nodeset_id_range> [color <color_spec>] [add]
draw sideset <sideset_id_range> [Color <color_spec>] [add]
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
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.
The expression as a whole is not wrapped in curly braces "{" and"}".
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]