Container Entities

MotionView supports and encourages a modular model building approach. Different entities can be aggregated into containers, thereby arranging a model into a collection of different assemblies or sub-systems. Model of any level of complexity can be organized in a hierarchical fashion. Moreover, entities needed to simulate specific event or analysis can be a different aggregate. It is highly recommended to model any mechanical system model this way as it provides lot of benefits to an analyst even though it takes some initial efforts to plan and organize a model.

Some of the benefits are:

•	Provides clear understanding of various sub-systems or aggregates involved.

•	These container entities can be deactivated or activated in one click, which is useful while debugging a model.

•	The container entity created can be exported to a definition file and re-using it in a different model.

For example, a complex model contains many hydraulic actuation systems. It is sufficient that such a system is modeled once, that contains its components, joints, forces and other entities. The system definition can be exported to a system definition file and reused multiple times to define other actuation systems. Moreover, the same system definition can be used in a different mechanical model that has same entities for the actuation system.

MotionView offers the following container entities that help such a modeling approach:

System

Assembly

Analysis

Click on the individual links above to learn more about each type of these container entities.

•	Any type of model entities, such as bodies, points, joints etc., can be children to these containers.

•	Entities external to these containers can be passed as attachments. Attachments are way of declaring local variables and referring entities external to the container to these variables. That way, a container entity can be an independent module and be used in other models.

•	Containers are definition based. Each container entity refers to a Definition block and can also refer to a Data block in the MDL.

While all of the above container entities are conceptually similar, they are differentiated for sake of certain specific usages.

•	System and Assembly can be considered as Model containers.

•	Analyses are event or task containers. They can contain system or assembly and other modeling entities that represent an analysis event over the MBD model. A model can contain many analyses, however only one analysis will be active at a given instance.

For example, a four cylinder engine mechanism can be modeled by having a system or assembly for each cylinder aggregate that contain a cylinder, piston, connecting rod and their joints. If a kinematic analysis has to be performed over this model by applying a known motion to the crank shaft, this motion along with the relevant outputs can be modeled in an Analysis container entity. Another analysis could be a dynamic analysis, where, the piston experience gas forces. These forces and any other entities required to simulate this dynamic event can be defined as another Analysis container.

Note	The above two analyses are mutually exclusive (one analysis is inactive, while the other is active).