Abaqus Interface

Overview of the Abaqus Interface.

Supported Abaqus Profiles

Standard3D
Generates a deck for three-dimensional models containing bar, shell, and solid elements for use with Abaqus Standard.
Standard2D
Generates a deck for two-dimensional models containing planar or axisymmetric elements for use with Abaqus Standard.
Explicit
Generates a deck for use with Abaqus Explicit.

Import and Export

  • HyperMesh places all elements into separate components, based on sectional property. Each component is written out from HyperMesh as an element set in the Abaqus input deck.
  • Export legacy comments added to export decks with old comments. Do not export ELSET with the same name as the component.
  • Although HyperMesh supports 160 characters in entity names, Abaqus output files are truncated at 80 characters to match the Abaqus name support level.
  • Loads and constraints are organized under load collectors in HyperMesh and added to a load step for the *STEP card in the Abaqus history definition. If loads are applied to node or element sets, you can resolve these sets to individual nodes or elements by enabling the Expand loads on sets option in the Import Options dialog.
  • Output options are organized under output blocks in HyperMesh. These output blocks also need to be added to load steps.
  • Resolve sets into nodes or elements, which are defined using the GENERATE parameter, using the Solver options in the Import Options dialog. This is useful when nodes/elements are renumbered due to ID conflicts during import.

Syntax

  • HyperMesh supports some abbreviated key words and parameters.
  • All Abaqus keywords and parameters supported in HyperMesh are not case insensitive.
  • HyperMesh ignores spaces in keyword lines.
  • HyperMesh supports quotation marks around component (ELSET with sectional properties) names, which is especially useful for names that begin with a number.

HyperMesh Operations

  • Warnings and error messages are written to a file named abaqus.msg. Unrecognized lines are written to a *.hmx file. These files are created in the same directory from where HyperMesh is launched.
  • Step time calculations can differ between HyperMesh and Abaqus (Explicit analyses), therefore you may find differences between reported values in the Abaqus status (.sta) file and the Time subpanel of the Check Elems panel. The values reported by HyperMesh are close estimates of the step time; refer to the Abaqus documentation to learn about the factors that Abaqus/Explicit uses to reach the final result.

Migration from Component Dependency

The following dependency of solver keywords and corresponding definitions are changed from the component entity:

  1. ELSET from *ELEMENT is removed from component. The ELSET is moved to the set entity.
  2. Indirect or direct property assignment leads to ELSET on *ELEMENT with the name referred from the property name in the HM session.
Import options and their behavior
  1. Import by HM comments

    HM comments are honored for component, property, and material.

  2. Import by Property

    One component per property is created.

  3. Import by Material

    One component per material is created.

  4. Import by one component

    All the elements are organized to one component.

Export behavior
New HM comments are created based on the above import options for components, properties, and sets that were created from components. For all the below, a new set for each property is created.
For export from Import by HM comments:
  1. Component – ELSET on *ELEMENT is removed. New HM comment with property name is also added along with name of the component maintained.
  2. Property – New set-based property comment is used.
  3. Set – A new element set is created using the same component name and HM comment added to refer that the set is coming from component.
For export from Import by property:
  1. Component – ELSET on *ELEMENT is removed. HM comment is changed with component name as property name along with additional property name.
  2. Property – New set-based property comment is used.
  3. Set – A new element set is created using the same component name and HM comment added to refer that the set is coming from component.
For export from Import by material:
  1. Component – ELSET on *ELEMENT is removed. HM comment is changed with component name as property name along with additional property name.
  2. Property – New set-based property comment is used.
  3. Set – A new element set is created using the same component name and HM comment added to refer that the set is coming from component.
For export from Import by one component:
  1. Component – ELSET on *ELEMENT is removed. HM comment is changed with component name as one HM component.
  2. Property – New set-based property comment is used.
  3. Set – A new element set is created using the same component name and HM comment added to refer that the set is coming from component.

Degenerated Brick Element

Elements that are defined in one configuration can be degenerated or collapsed to create other configurations, while still preserving the number of nodes and element type in the original configuration.

For example, the HyperMesh Qaud4 element can degenerate into a Tria3 element, but when exported, the four nodes and quadrilateral element information is written in the solver deck.

Degenerated brick elements are either Hex8 or Hex20 elements, collapsed into a wedge element (Penta6 or Pet15). Penta6 (Element configuration 206) is a 3D, 1st order, triangular prism shape element with a 6 noded order as shown in Figure 1. Hex8 (Element configuration 208) is a 3D, 1st order, brick shape element with a 8 noded order as shown in Figure 2. The Degenerated Brick (Element configuration 206) option is a 3D, 1st order, triangular prism shape element with a 8 noded order as shown in Figure 3.

Standard node order for a 1st order, penta6 element will be 1, 2, 3, 4, 5, 6. In cases of degenerated brick elements, the node order will be 1, 2, 2, 4, 5, 6, 6, 8, with nodes 2 and 6 being repeated during export. The same node repetition method is used for a 2nd order, degenerated brick element, but nodes 2 and 6 will be repeated twice and node 18 will be repeated once (1, 2, 2, 4, 5, 6, 6, 8, 9, 10, 2, 12, 6, 14, 15, 16, 17, 18, 18, 20).


Figure 1. Element Configuration 206, 6-Noded Penta


Figure 2. Element Configuration 208, 8-Noded Hexa


Figure 3. Element Configuration 206, 8-Noded Penta

Since the 8-noded, hexa element is degenerated into a 8-noded penta element, the 1st order brick element option is added under the 6-noded penta (Element configuration 206) and the 2nd order brick element option is added under the 15-noded penta (Element configuration 215).

Duplicate Names

Abaqus is a name-based solver which uses a label/string to reference entities like sets, surfaces, material, coupling, and so on. Reusing a name is quite common in Abaqus across solver keywords. It is generally allowed in HyperMesh to reuse the same name across keywords if those keywords are mapped to different entities. There are certain HyperMesh entities which are shared by different keywords. In those cases, it becomes an issue to share the same name across different keywords mapped to the same HyperMesh entities.

For example, the set entity is shared by a node set (*NSET), element set (*ELSET), set segment-based keyword types (*SURFACE), and other keywords mapped to the set entity. To ensure that the same name can be shared across the above-mentioned entities, we have introduced a name pool within the set entity and divided it in six pools as below with complete import/export support and support for creation in the usual Entity Editor way.

  Card Image Keyword
POOL-1 NSET *NSET
POOL-2 ELSET *ELSET
POOL-3 SURFACE_ELEMENT *SURFACE, TYPE=ELEMENT
SURFACE_NODE *SURFACE, TYPE=NODE
SURFACE_COMBINE *SURFACE, COMBINE
CUTTING_SURFACE *SURFACE, TYPE = CUTTING SURFACE
ANALYTICAL_RIGID_SURFACE *SURFACE, TYPE =SEGMENTS | CYLINDER | REVOLUTION | USER
SURFACE_CROP *SURFACE, CROP
POOL-4 NODALTHICKNESS *NODAL THICKNESS
POOL-5 DISTRIBUTION *DISTRIBUTION
POOL-6 EMBEDDED_ELEMENT *EMBEDDED ELEMENT

Compound Sets

Features of compound sets.

The main features of compound sets are as follows:
  1. The new set configuration is introduced for collected use cases.
  2. The new set holds a list of hidden child sets.
  3. The new set refers to a list of hidden sets.
  4. Hidden sets do not occupy NAME or ID space and are hidden in the master/assembly view.
  5. The child set is displayed with a master label ID along with its respective contents only in the respective include/assembly view.
  6. The hidden child set is not visible for any reference assignment. Only the master set is visible for assigning contacts or loads.
  7. Exporting writes the hidden sets using the name and ID from the master.

Redundant Entity Management for Sets

Set types supported:

  1. Element set
  2. Node set
  3. Set segment/Surface

Referred entities:

  1. Group
  2. Load collector
  3. Loads
  4. Loadstep
  5. Output block
  6. Property
  7. Rigid body
  8. System
  9. Set - Sets refereed by other sets

The above referred entities that call for sets that are undefined are addressed with redundant entity management.