Home > User Guide > Understanding Assembly Modeling

Assembly Modeling vs Part Modeling

Assembly Modeling and Part Modeling are two different "domains" in a modeling application. Part Modeling defines geometry and properties for objects or sets of objects, while Assembly Modeling imposes an associative (that is, grouping) structure and property overrides on "part" data. This will feed into the design as two "modes" of operations – part (modeling) mode and assembly (modeling) mode. Corresponding to these two modes are two "domains" of the application: the part and assembly domains.

Note:  The term "domain" in this context refers to a conceptual segregation of program constructs. For example, entities reside in the part domain, while model objects reside in the assembly domain. Objects in the assembly domain are manipulated by assembly mode operations, while objects in the part domain are manipulated by part mode operations.

Topics include:

Assembly Modeling Design Constructs

Several major design issues which occur in assembly modeling, but not in part modeling, necessitate management of corresponding design constructs. Some of the more important of these issues include:

Sharing of Entities

Because multiple components of an assembly can share a single part through model-references, an ENTITY pointer is not necessarily one-to-one with a physical object in the assembly. This is managed by introducing the concept of a "component entity" (designated in code by a pointer to a component_entity_handle), which respresents a (component, ENTITY) pair. Such a pair is one-to-one with objects in the assembly, and is the generalization of the concepts ENTITY in part modeling.

Cross-history Stream References to Entities

One of the requirements for assembly modeling is that each model in the assembly be independently "roll-able"; that is, that each model can be bound to its own history stream. It is also necessary for entities in an assembly model (for example, property-owner attributes) to be able to refer to entities in a sub-model. In ACIS, entities in one history stream are not allowed to point at entities in a different history stream, because rolling the latter stream could result in an invalid pointer in the former stream. This rule is in conflict with the need for cross-history stream references.

This is managed by introducing the concept of an "entity handle". An entity handle is an assembly domain proxy for an ENTITY (which is a part domain object). An entity handle lives outside of history (it is not an ENTITY), and so will not become invalid even if the ENTITY is rolled away.

Representation Management

A common concept in assembly modeling is "representation management", which is used to control the memory footprint of the assembly. When representation management is implemented, the (heavy) B-rep representation of a model can be removed from memory in favor of a lighter representation, such as facets or a bounding-box. ACIS Part Modeling uses pointers to ENTITY as the identifier for entities; if the model is swapped out (causing the ENTITY object to be deleted) and read back in, this identifier can change when the ENTITY is re-allocated. This is in conflict with the needs of representation management. This is also managed by the "entity handle" concept. The entity_handle remains in memory even when the corresponding entity has been swapped out.

Active Model

One major difference between assembly modeling mode and part modeling mode is the concept of an "active model". The ACIS history mechanism is designed around the concept of a default history stream. Generally speaking, ACIS routines that modify entities should only be called when the default stream is set to the stream which owns the entities. Because each assembly modeling model can be bound to its own stream, a mechanism is required to "activate" a model (that is, make its history stream the default) before performing part modeling operations on the entities in that model.

In addition, ACIS has other global parameters that affect modeling operations (for example, resabs); these too may be different for different models. The various characteristics of a particular model (for example, history stream, units, and resabs) can be thought of as defining a part modeling context. Assembly modeling objects, on the other hand, live outside of history and are unaffected by part modeling parameters such as resabs and units.

In other words, assembly mode operations are not associated with a particular modeling context, while part mode operations are. Whenever an assembly mode function needs to perform part mode operations (for example, calculate the bounding box of a sub-model), the proper modeling context must be set; this is done by making the model within which the operations take place "active".

ACIS Assembly Modeling provides a set of macros, (API_)MODEL_BEGIN and (API_)MODEL_END, which activate and deactive a particular modeling context in a nested manner; these should be used when you need to manipulate entities while writing assembly modeling functionality, such as counting the number of faces in each component of an assembly. These macros are not necessary, however, when you are performing operations, for example a Boolean, on entities through your existing part modeling interface; it is assumed that your existing part modeling interface already ensures that the correct modeling context has been set. In this case, you need only notify assembly modeling of the type of change that you have made to the part by calling the contents_changed method of asm_model. For more information on this topic, refer to the sections Assembly Modeling Macros and Notification Mechanisms and Entity Managers in Assembly Modeling.

The difference between assembly modeling mode and part modeling mode is also reflected in the naming convention for assembly modeling interface function. ACIS Assembly Modeling adds two prefixes for interface functions to the existing "api_*": "asmi_*" and "api_asm_*". The "asmi_*" routines are "assembly mode" interface functions; ENTITY and ENTITY_LIST do not appear in their signatures, and they are not associated with a particular history stream. The "api_asm_*" routines are ACIS API, that is part modeling mode, functions which are part of the assembly modeling component. As with any other API function, they must be called only while the modeling context associated with the entities upon which they act are active.

Related topics:

Assembly Modeling Overview
Basic Concepts in Assembly Modeling
Assembly Modeling Tutorial
Properties in Assembly Modeling
Assembly Modeling Save and Restore
Standard Workflows in Assembly Modeling
Assembly Modeling Limitations

[Top]

© 1989-2007 Spatial Corp., a Dassault Systèmes company. All rights reserved.