Guidelines

adapter guidelines

The previous subsections have demonstrated ways in which adapter models can be safely used, ways in which custom adapters can aid in creating mixed system models, and ways in which the mathematical structure of a model can be inherent problematic. We summarize those findings here into a set of general guidelines.

Before attempting to connect Modelica-based and Simcenter Amesim legacy subsystems, one should:

1. Understand the system level model that is desired

Begin with the end in mind. Is there a benefit to separating my model into subsystems that come from different modeling paradigms? Is there a way in which the entire model could be created completely with Modelica-based models or completely with Simcenter Amesim legacy models? If so, then it is generally speaking safest to work with homogenous models homogenous system since all components were generated with the same modeling paradigm in mind.

If it is necessary to create a heterogeneous system heterogeneous system model, then one must determine the appropriate subsystem boundaries. It is generally recommended that users should avoid connecting components at the "atomic" level. For example, connecting a Modelica-based mass with an Simcenter Amesim legacy spring damper is both illogical (because a more homogeneous model is possible) and error prone (as demonstrated in the advanced examples). Rather, it is better to find a natural boundary between subsystem models. For example, connecting a hydraulic circuit with Simcenter Amesim legacy libraries and a Modelica-based electric circuit via a transducer model is a reasonable approach (see figure below).

Figure 44: Heterogeneous system model with natural subsystem boundaries

In this example, there is a concrete benefit to heterogeneous modeling approach. The Simcenter Amesim legacy libraries are well-suited to hydraulic system modeling, and Modelica’s acausal approach is well-suited to electrical network modeling. Creating subsystem boundaries around the electro / hydraulic interface (the transducer model) creates a physically meaningful separation between the modeling paradigms.

Once subsystem boundaries are defined, make sure that the connections between subsystems adheres to the original assumptions about the system level topology. What is the power flow through the subsystem components once the system level model has been assembled? For example, if one creates an electrical network with an internal ground, be mindful of how that circuit will interact with other subsystems to which it is connected. Are portions of the model being grounded by virtue of the system level connections?

2. Understand the boundary conditions being imposed by the adapters

boundary conditions

Adapters essentially impose boundary conditions on each subsystem to which they are connected. Because they assign causality, they specify which variables are considered known and which are unknown within each subsystem. If the user does not pay attention to the boundary conditions they have assigned with the adapters, they can create singular systems. In order to provide a full rank system of equations, there must be a linearly independent set of equations provided. For example, across variables cannot be considered unknown on both sides of a dipole. One would create a singular system if they tried to specify that both ports of a mass have force as an output, or that both ports of a resistor have voltage as output.

3. Understand the modeling conventions underlying each subsystem

conventions modeling

Before one can connect subsystems to each other, it is critical to understand the modeling conventions used by each subsystem. This is particularly important when physical ports are used, because the conventions that determine the meaning of each variable must be consistent with the adapter one selects.

What is the physical meaning of a variable on each side of the interface? What does a positive / negative value mean for each variable, and is it consistent between the two subsystems? For example, in mechanical models, what does the value of the velocity variable indicate for the particular ports that are connected? Is it the same as the "bulk" value of the model (e.g., velocity on the right port of an Simcenter Amesim legacy mass model) or does it include a sign flip (e.g., velocity on the left port of an Simcenter Amesim legacy mass model)? In electrical models, which pin reflects the current flow in the positive direction? When submodels are asymmetric in the interpretation of the port variables, it is critical to understand how to interpret the variables and what the ports are being connected to.

Does the port variable use an absolute or relative frame of reference? For hydraulic models, is the pressure absolute or relative? For electrical models, is the ground assumed to be 0V, and where is it in the system level topology? For mechanical models, how are the position variables measured? While Modelica-based models use an internal frame of reference for each component, Simcenter Amesim legacy models use an absolute frame of reference across the entire system (equilibrium position of inertia elements). If the relative position of components is important, heterogeneous modeling can be mathematically impossible in some cases.

Another important modeling convention to be understood is the initialization scheme. Consider a heterogeneous system where the interface connects a mass on one side and a damper on the other. Both of these subsystems may require a way to initialize the velocity. Setting the initial velocity of the mass to 10 m/s while setting the initial velocity of the connected damper port to 0 m/s would lead to an error (best case scenario) or ambiguous initialization (worst case scenario). The two subsystems contain independent initialization routines, and so the user must take precautions to ensure that the system level model is initialized consistently.

The guidelines provided here are intended to force the user to think clearly about how they are mixing heterogeneous system models. While adapters are useful tools, they are not magical. It is the responsibility of the model developer to understand what is being connected and what that connection means. With careful consideration of the above issues, model developers can create heterogeneous system models that combine the strengths of both Modelica-based and legacy libraries.