Abaqus model organization from HyperMesh 2022 and later

Abaqus model organization in 2022 and later


Why change model structure?

This is part of a long-term project, whose final intent is to bring more advantages to Components, which will be merged with the entities Paets introduced from version 14.0. This project is needed to bring HyperMesh at an entreprise level of modeling, for allowing collaborative work. Thisincludes a better interaction with PLM systems, but not only. Even users not dealing with PLM will get benefits from Parts:


Below are some contents of interest for showing some benefits of these parts.

Discover the concepts of modularization:


Creating instances:


Dealing with several positions of a part inside the same model:




What has changed?

Before detailing the changes, an explanation regarding direct and indirect assignment is necessary.


Direct assignment means the property is directly assigned to elements. Implicit solvers such as Abaqus, OptiStruct, Nastran natively use direct assignment.

More precisely the property id is called in the element card (CQUAD, …) and there is no solver entity defining what is a physical part.


Indirect assignment means the property is assigned to a solver entity defining the physical part. Explicit solvers (LS Dyna, Radioss, PamCrash) are using natively indirect assignment.

For Radioss for instance physical part is defined with keyword /PART, which is a container for the elements. Then property id is referenced in /PART card, not in the element card.

For multiple versions, HyperMesh allowed direct assignment for implicit codes, and indirect assignment for both implicit and explicit codes.

When the user set up indirect assignment for implicit codes like Abaqus, the direct assignment required by the solver was realized during the solver deck export. The indirect assignment information was kept as a HyperMesh comment in the solver deck.


Starting 2022, we are aligning back HyperMesh with Abaqus definition (direct assignment), which means the property owns the part definition. In other words, one physical part, one property.

Then, creating a model from scratch in 2022, a property must be assigned to each physical part, and a *ELSET is populated at export for each property, with HM_prop prefix.



What is the impact when loading models written with HyperMesh 2021 or earlier?

In this case, every *ELSET related to component in 2021 is exposed (it was not exposed before), and a new *ELSET is created for each property, named HMPROP_propertyname.

Short term, and from 2022.1, we allow our users to recover Abaqus 2021 structure through a solver export option. This has no effet on the ELSET starting with HM_prop, which are the new standard.



If you import back such model in HyperMesh 2022, you will retrieve the same organization, with the extra additional sets:



How far am I concerned by this change?

Prior to version 2022, we could distinguish 3 different modeling strategies for defining physical parts:


Use case #1:

One property per component

Use case #2:

Multiple components pointing to the same property

Use case #3:

Multiple properties per component

Direct/indirect assignement

Indirect generally used

Indirect frequently used



Automotive, Railway

Heavy industry, Energy, oil&gas



2D mesh, parts with uniform thickness

3D mesh

2D mesh, parts with different thickness (composite)


Allows to retrieve quickly the BOM structure in the FE model (component + property + material)

Mostly by commodity, relying on HyperMesh mode organization (components) instead of Abaqus properties

Required as thickness is available only in the property


For use case#1, you need to consider now your property as your component from a solver point of view. Which means that once our mesh is in the component, go to property and assign the elements to your property.

For easier reading, define the same name for your property than from your component. The macro in the link below can be used for such purpose:



You can then use the Property browser to get access back to a BOM-like visualization:


For use case #2, you need first to create one property for each component, then to assign the elements of each component to the targeted property. As for use case #1, using the same name for component and property is recommended.

For creating as many properties as components, you can use the script below:



For use case #3, let us focus on a single component with variable thickness. You can still assign one sole property to all the elements so that the elements are seen as belonging to the same part. Then you can use the Map Thickness to apply a nodal thickness to your elements:


With the direct assignment, how to preserve the property assignment when remeshing the elements?

Please make sure to activate the preference “Retain element values”:


Do these changes in HyperMesh also affect the model organization in HyperView?

When loading results in HyperView, for retrieving the same model structure you must load the odb file and request in the reader options to organize parts based on properties.



I load an inp file generated with 2021.2 or below. If I am OK with the new structure, can I safely remove the ELSETs which were connected to the components?

First make sure you understand the new model organization.

Then, if you do not have any automation related to your parts, no component-based contacts, you should be able to remove the unnecessary entity sets by using the code below. It is better to make sure before using the code your ELSETs are not referenced in other entities apart from the component.

*createmark comps 1 all

set CompList [hm_getmark comps 1]

foreach Comp $CompList {

     *createmark sets 1 "contains value" name [hm_getvalue comps id=$Comp dataname=name]

*createmark sets 2 "contains value" cardimage "ELSET"

*markintersection sets 1 sets 2

*deletemark sets 1




I used to rely on components for creating my contacts, in order for my contacts to get automatically updated when I remesh my model. How do I proceed in 2022 and beyond?

The Auto contact still allows to create primary and second entities from components, but the sets will not be updated anymore if you change the elements within a set.


Work is in progress to replace components by properties for the Auto contact.

In the meantime, it is recommended to: