Using Model Data and External Tables

Normalized Stress Example

In this example, an external XML resource file will be added to the model and result that contains yield values. This table will be used to create two datatypes: “Yield” and “Normalized vonMises”:

normalized_stress_ex_expr_bldr

The header portion of the XML defines what operator libraries are used, what resources will be attached, and how the model will be extracted.

expr_bldr_xml_header_example

•	using: operators are defined in libraries that are linked to the analysis through the using tag. In order to call an operation, the library that it belongs to must specified in the analysis with the using tag.

•

resource: a resource can be any file recognized by HyperView readers, or any XML file that follows the Result Math export schema. Each resource must have a unique id. The @filedir variable expands to the directory that contains the XML file. A resource is not strictly model or result content, but can contain both. For example, the files above contain model content from both the op2 as well as the dat file, which necessitates the use of the optional model tag.

•

model: In cases where additional processing is necessary to resolve content conflicts, the model tag is used to resolve these. The example above instructs Result Math to accept model content from the dat resource. If this were not specified, there would be duplicate ID errors when this XML file is being read as both the “dat” and “op2” resources would send duplicate node, element and part information. Result Math supports extraction of model content when reading input deck resources. These include properties and materials, along with the values attached to them.

The content of the resource file “ext” is a set of ID-value pairs that define material-bound real scalar values:

expr_bldr_xml_example2

Since the values are bound to materials, it is necessary to transform them to their corresponding elements using the model operator “BCMatToElem”. By creating the Yield datatype, the output of this operation can be visualized as elemental scalars:

expr_bldr_xml_example3

The declaration of a data type must include the following attributes to be valid:

•	id: all datatypes must have an ID, and all ID’s within the analysis must be unique. The ID is used as the title of the datatype in the contour panel, unless overridden by the title attribute.

•	bind: this defines the type of entity the data type is bound to, and can be “node”, “elem”, or “part”.

•	format: can be “scalar”, “vector”, or “tensor”.

•	pools: A list of one or more pools that this data type will span, separated by semi-colon. The HyperWorks application will use this information in addition to the pools contained in the model to describe what pools this data type is valid for.

When the data type is called from a HyperWorks application, it is evaluated. In this case, the model operator “BCMatToElem” is called with tables from the model and external resource. The table address contains a resource qualifier, although this is only necessary when the same table exists on more than one resource.

The datatype for “Normalized vonMises” is similar to yield, and demonstrates the use of temporary tables as well as a sequence of calls to operators.

expr_bldr_xml_example4

Two tables of element bound scalars are created to store vonMises stress and material yield. These tables are filled as the data type is being evaluated, and are passed from one call to the next. The last call Divides the tables filled by the BCMatToElem and ScalarExtract and stores normalized vonMises stress into the @datatype_value table.