Abaqus model organization from HyperMesh 2022 and later

Michael Herve_21439
Michael Herve_21439
Altair Employee
edited April 15 in Altair HyperWorks

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:

  • Better capabilities for identifying instances
  • Better modularization of the model, and possibility to define several configurations (multiple positions, different load cases for explicit analysis) within the same hm file
  • Consistent modeling across all solvers
  • Easier conversion across the different solver profiles

 

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

Discover the concepts of modularization:

https://community.altair.com/community?id=kb_article&sysparm_article=KB0010112

Creating instances:

https://youtu.be/XrHvD5jV3is

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

https://youtu.be/bdeVPw0SQzA

 

 

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.

 image

image

 

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.

image image

 

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

 imageimage

 

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

Direct

Who?

Automotive, Railway

Heavy industry, Energy, oil&gas

Aerospace

What?

2D mesh, parts with uniform thickness

3D mesh

2D mesh, parts with different thickness (composite)

Why?

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.

image

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:

https://community.altair.com/community?id=altair_file_exchange_article_view&sysparm_article=KB0121743

 

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

image

 

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:

https://community.altair.com/community?id=altair_file_exchange_article_view&sysparm_article=KB0120717

 

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:

image

 

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

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

image

 

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.

image

 

 

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.

image

 

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

In the meantime, it is recommended to:

  • Use Extend surface to features when populating contacts with Auto Contact

image

  • Use the following preference for automatic update of segments when remeshing parts (2D mesh or tetra mesh):

image

  • Use Replace to replace the component from model browser:

image