In the example below,
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”.Figure 1.
The header portion of the XML defines what operator libraries are used, what
resources will be attached, and how the model will be extracted.
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:
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:
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 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 the 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.
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.
