User Method Registration

Method registration relies on two .xml files that must be available in the same directory:
  • StressToolMethodRegistration.xml
  • StressToolAttributeRegistration.xml

The default location of these files is installdir\hwdesktop\hm\scripts\EngineeringSolutions\aerospace\StressTool\WorkingDirectory. You can copy these files into any working directory and point to StressToolMethodRegistration.xml.

Attribute Registration

Registered attributes are either model information queried from the HyperMesh database or result information queried from result files. Result data types must match names in the result file. Most of the time, the result reader provides aggregated vector or tensor data types. For better portability of method registration, it is recommended to use such aggregated data types instead of direct raw scalars that are subject to change depending on element formulation. For example, cbar versus cbush force, or depending on the file format used, even for the same solver (*.xdb and *.op2 have different spelling scalars). All result attribute paths (key “value=”) start with HMDb.Results. HMDb is the design point that will be queried. Whenever the design point is made of several elements, the framework will loop through the design point content.

An attribute can be defined in a flexible way with a fully qualified path. By default, property or material-based attributes will be queried from the structural property’s property entity. If none are available, the query is performed at the element’s property level. If you want to enforce a path to query elements no matter what the structural property, you can fully qualify the path to include the element.
  • HMDb.property.PCOMP_MID.MAT8_Xt will query the ply’s material Xt allowable based on the order of precedence.
  • HMDb.element.property.PCOMP_MID.MAT8_Xt will always use the local element’s property no matter which property is assigned (or not) to the structural property.
In some situations, the framework cannot resolve any precedence, such as for thickness for panel_metallic.
  • HMDb.element.thickness will retrieve elemental thickness in a panel (metallic and composite).
  • HMDb.structuralproperty.thickness enforces to use attribute thickness for Panel_metallic.

If an attribute can have multiple values on an element, certification will manage during the query loop layer per layer.

Method Registration

Methods are registered in the following .xml format:
  • name
  • type
  • category
  • display name
  • path
Two tags are mandatory to specify input parameters and method outputs:
InputArgList
Define mapping between method inputs and attributes defined by the name in the AttributeRegistration file. The list of parameters must be ordered in the same way as method arguments.
Parameters mapped to attributes are automatically queried and passed to the method for evaluation. Some of these attributes are not editable while some can be edited in the HyperMesh database. In some scenarios, method requires some other input that has no existing placeholder in HyperMesh:
  • Material extra allowable is not available in the solver decks
  • Method specific buckling factor is not available as a regular entity data name
The database can be extended by dynamically adding a placeholder as metadata. The parameter will be declared as userinput=”1”. Then entitytype= a valid HyperMesh entity type where the metadata will be attached to. Typical use cases are:
  • Design point method
  • Structural property
  • Property
  • Material
You can define a default value with value=””. Only float values are supported.
Whenever a method is attached to a design point set where design points have structural properties assigned, the tool parses the database to search if such metadata already exists. If not, metadata will be created with the default value. When you save your model, metadata that was created will be retrieved when the file is opened.
Metadata can be created by an external script. As soon as the metadata name matches the parameter set as user input in the method registration, it will be used.
OutputArgList
Methods can output multiple results. Variable number of outputs is not supported. You can give a display name for each method output. This name will become the header of the method table column.

Sorting

Using method registration you can add a sort block. As a result, the method will still be evaluated for each and every entity inside design point as well as each loadcase. An aggregation is performed on a domain using a metric and envelope type. The result of this aggregation is that table output by method will retain only aggregated values. The envelope type can be spatial and/or on loadcases depending on the domain.
  • The type of envelope is: Min| Max| AbsMin| AbsMax.
  • The value can be any float parameter from InputArgList/OutputArgList. It is used as a comparison metric.
  • Domain can be a cumulative list among keys: DDP |elementid |layerindex |loadcase.
As soon as one of these keys is missing an aggregation occurs in this dimension. For example, a domain made of successive calls of:
  • DP|elementid|layerindex: On each layer retains the critical metric across loadcases (LC).
  • DDP|elementid: Retains one value per element which is a critical metric across layers and LC.
  • DDP|elementid|loadcase: Retains one value per element per LC.
  • DDP| loadcase: Performs spatial aggregation across elements (layers if applicable) per LC.
  • DDP: Retains the critical metric across LC:
    • If method was element/layer based there will be spatial aggregation.
    • If method was a DDP level method (one value per DDP) it is an envelope.
Restriction: As soon as a sorting is done, the output table keeps the whole row with all of the values (input/output) corresponding to the critical metric value. By doing a sorting across a column, you lose a dimension, which might prevent full contouring on sorted dimension.
  • Whenever there are critical values across loadcases, contour is available only for envelope loadcases.
  • Whenever results across layers are aggregated, contour is available only at the element level.
  • Whenever an aggregation is done across elements (on a design point) the table will have the following: DDP|elementid|loadcase|..inputs|..outputs| metric, where metric uses critical values. As a result, only one element ID is kept per design point. The contour method feature has the ability to select ddpid as an entity, which contours a constant value on all elements inside the design point.

Aggregation

In addition to post evaluation sorting, attributes can be sorted before sending them to method for evaluation. This enables some flexibility in method evaluation. For example, you can declare the method input parameter as:

<Parameter name = "Composite Stress XX

perlayer="0"

sort=”min|max|minmax|sum|avg|absmin|absmax” (optional)

/>

All layers will be queried for Sxx before calling a method, and only the min or max will be retained and sent to method. In the case of minmax, both the min and max values are sent as a vector to method. The sort key is optional. If sort is not requested, all layer values of Sxx will be sent at one time (as a vector) to the method. The attribute aggregation types are (exclusive choice):
  • perlayer=”0|1”
  • perelement=”0|1”
  • perloadcase=”0|1”

You cannot mix these keys and only one of them can be “0” at a time. This means that you cannot aggregate the attribute both across layers and loadcases at the same time. This enables you to create a “designpoint method” level. For example, panel shear buckling considers the maximum shear stress XY among its elements. This value will be sent for math evaluation.

Restriction: Currently, the aggregation of attributes before method evaluation prevents the method from exporting results on aggregated dimension. If you use perlayer=”0” at any input parameter, it is a valid use case if you do not expect to output a value layer per layer. Method will output margin of safety on an element basis. As a result of this limitation, it is not possible for composites to evaluate ABD matrix and compute failures layer per layer with user-defined methods. An internal method such as First_ply_failure manages it internally.

You can mix attribute aggregation and method sorting. In some cases, results might be more useful from tabular data exported to a report than contour, considering some of the limitations. The contouring tool has a filter for layer and loadcase and a selector for data type to plot. Only float data types are available for contouring. In the event of LC envelope (by sort) it is not possible directly to contour “critical subcase ID” on all elements (subcase is now a string). Information is available in the loadcase selector that contours only elements that have the critical value for this selected loadcase.