EACM harmonisation

PDES, Inc. Offsite

Myrtle Beach, 20^thto 24^thMarch 2000

1. Introduction

The following harmonisation issues were addressed:

PDM and EACM properties:

the relationship between the property modules within the PDM module suite and the property modules within the EACM module suite;

AP 209 and EACM state and activity:

the relationship between the part 209/104 entities stateand analysis_step and the EACM modules state and activity;

AP 209 and EACM shell and beam properties:

the relationship between the part 209/104 entities for shell and beam properties, especially those that allow variation of properties with respect to position, and the EACM property modules;

AP 209 and EACM unstructured mesh:

the relationship between the part 209/104 approach to finite element model definition and the EACM unstructured mesh module.

Significant progress was made on each of these issues, as described in the following sections.

2. PDM and EACM property modules

The key harmonisation issue involved the relationship between:

• the PDM module independent_property; and
• the EACM modules property_space and property_value.

It was agreed that:

• the part 41 entity general_property corresponds to both the concept of 'property space' and the concept of 'property value' as defined in the EACM modules;
• the module independent_property within the PDM suite also encompasses both 'property space' and 'property value'; and
• the term 'property value' is not easily understood.

As a result of this agreement:

• the term 'independent property definition' will be used instead of 'property value';
• the PDM independent_property module will be split into three parts and renamed, as shown in the figure below;
• the EACM property_space module will be merged with the PDM property_space module;
• the EACM property_value module will be merged with the PDM independent_property_definition module.

Figure 1: Independent property modules

The agreement will be implemented by the following actions:

• David Leal will split the PDM independent_property module, and will add contributions from the EACM property_space and property_value modules;
• Tom Hendrix of Boeing will be the editor of the new property_space and independent_property_definition modules within the PDM suite;
• the other EACM modules will reference the new property_space and independent_property_definition modules within the PDM suite.

3. Part 104 analysis control and the EACM

The key harmonisation issue involved the relationship between:

• the part 104 analysis control entities stateand analysis_step; and
• the EACM modules state and activity (containing ARM and MIM entities of the same name).

The EACM MIM entity state is a subtype of product_definition in part 41. The EACM MIM entity activity is a subtype of action, also in part 41.

It was agreed that:

• the part 104 analysis control entity state has the same semantics of the EACM MIM entity state, but with the constraint that the part 104 state is the subject of a finite element analysis; and
• the part 104 analysis control entity analysis_step has the same semantics of the EACM MIM entity activity, but with the constraint that the part 104 analysis_step is the subject of a finite element analysis.

It was further agreed that an interface between part 104 and the EACM in this area would give the following benefits:

• additional properties of a state within a finite element analysis (such as a property distribution with respect to position described by a mathematical function) can be defined using the property_definition entity within part 41 and the mathematical_function entity within part 50; and
• additional properties of an analysis_step within a finite element analysis (such as a property distribution with respect to time) can be defined using the action_property entity within part 49 and the mathematical_function entity within part 50.

The form of the interface between part 104 and the EACM in this area is shown in the figure below. The interface is implemented by a MIM entity with multiple inheritance, which can be contained in a module that extends the capabilities of AP 209.

Figure 2: Activity and state in part 104 and EACM

The colour coding is as follows:

pink

part 104 entities

light blue

EACM MIM entities

yellow

part 41 entities

light green

part 104/EACM interface

4. Part 104 shell and beam section properties and the EACM

The key harmonisation issue involved the relationship between:

• the part 104 element property entities surface_section_varying, surface_section and curve_section; and
• the EACM modules property_distribution and independent_property_definition (formerly property_value) (containing ARM and MIM entities of the same name).

The EACM MIM entity property_distribution is a subtype of property_definition in part 41. The EACM MIM entity independent_property_definition is a subtype of general_property, also in part 41.

It was agreed that:

• the part 104 element property entity surface_section_varying is a specialisation of the EACM MIM entity property_distribution;
• the part 104 element property entity surface_section is a specialisation of the EACM MIM entity independent_property_definition;
• the part 104 element property entity curve_section is a specialisation of the EACM MIM entity independent_property_definition.

It was further agreed that an interface between part 104 and the EACM in this area would allow section property definitions contained within part 104 to be associated with any product. Hence it would be possible to associate:

• curve section properties with a pipe or structural member defined within AP 227
• surface section properties with a stiffened plate structural assembly defined within a ship AP; and
• curve or surface section properties with an automotive part defined within AP 214.

The form of the interface between part 104 and the EACM in this area is shown in the figure below. The interface is implemented by a MIM entity with multiple inheritance, which can be contained in a module that extends the capabilities of any STEP AP.

Figure 3: Beam and shell properties in 104 and EACM

5. Part 104 finite element model and unstructured meshes in the EACM

At first sight it appears that the unstructured_mesh module within the EACM duplicates functionality within part 104. This is not the case because there are distinct differences in functionality as follows:

part 104:

Part 104 defines a complete finite element model rather than mesh topology. In part 104 there is no order to the elements of the finite element model. Hence a results field is defined by a separate instance of state_definition for each element within the model.

EACM:

The EACM considers only mesh topology and not a finite element model that uses the topology. Hence a mesh in the EACM is a subtype of topological_representation_item. An EACM 'unstructured mesh' is not completely unstructured because it defines an order to the cells of the mesh. This approach enable a field over the mesh to be defined by a single list of results that is interpreted cell by cell according to cell order.

The motivation of the EACM approach has been the efficient handling of very large results sets for structured and unstructured meshes. Using the EACM, the control values that define a field over a mesh can be held as a single list, whether or not the mesh is structured or unstructured.

It will be possible to fully integrate the EACM unstructured_mesh module with part 104, by:

• defining an association between mesh_cell (in the EACM) and element_representation (in part 104); and
• allowing the vertices of the mesh_cell to be derived from the nodes of the element_representation.

This is shown in the figure below.

Figure 4: Unstructured mesh in part 104 and EACM