Optional element
In this section, the use of connectors in combination with two different naming policies is explained.
Purpose
Connectors are modeling objects that translate between two different namespaces, usually caused by the use of different notations. To make an equation system or equation using notation ‘A’ usable in an equation system using another notation (‘B’), you need to specify a connector that provides all pertinent variables with a synonym complying to notation ‘B’.
It is also possible to use a connector to rename certain variables whose meaning changes when added to another equation system, e.g. if a variable’s superscript switches from “out” to “in”.
Concept of different naming policies with and without connectors
Should the brief introduction regarding the purpose of connectors be too confusing at this point, the following paragraphs will hopefully reduce this confusion. We start with the description of the two naming policies, which are available in MOSAICmodeling. Then, we show how equations (or equation systems) can change under these naming policies in combination with or without connectors.
Naming policies
We differ between two naming policies, which will be explained below.
- Naming policy “integrate”
- Naming policy “encapsulate”
The basic rules of the naming policy “integrate” are:
- If an equation or equation system (sub element) is added to a super equation system (super element), the sub element’s variables will get the namespace of the super element;
- If a sub element is connected to a super element, and both elements use different notations, then all variable names of the sub element have to be translated (by a connector) into the super notation;
- Attention: In any time the meaning of each variable has to be uniquely defined by the notation of its namespace. If different notations are used in sub and super element, each variable has to be translated. Otherwise the meaning of some variables coming from the sub element would be undefined in the notation (and therefore in the namespace) of the super element;
- Result: After parsing, all variables have a top level naming according to the super notation in the top level namespace.
The basic rules of the naming policy “encapsulate” are:
- If an equation or equation system (sub element) is added to a super equation system (super element), the sub element’s variables will get their own namespace;
- If a sub element is added to a super element by using a connector, only the variable names of the sub element that are translated by the connector will get the super element’s namespace;
- When considering the sub element, only the variables translated by a connector have a top level naming according to the super notation.
Combination of connectors and naming policies
We now demonstrate the concept of different naming policies with and without connectors for the equations and connectors below:
Equations:
(equation 1, namespace: e1)
(equation 2, namespace: e2)
Connectors:
(connector 1, may be applied on equation 1)
(connector 2, may be applied on equation 2)
Case A: naming policy “integrate” + connectors
In this case, the resulting equation system is:
(equation 1, namespace: e0)
(equation 2, namespace: e0)
As you can see, the policy “integrate” caused all variables to have the same namespace. The connectors renamed the variables , , and . Please note that the of the first equation and the of the second equation became the same variable in the final equation system. The final system contains four distinguishable variables (, , , and ).
Case B: naming policy “integrate” without connectors
Without connector, we have
(equation 1, namespace: e0)
(equation 2, namespace: e0)
Again, the policy “integrate” caused all variables to have the same namespace.The final equation system contains four distinguishable variables (, , , and ).
Case C: naming policy “encapsulate” + connectors
With the naming policy “encapsulate”, new name spaces are created:
(equation 1, no unified namespace)
(equation 2, no unified namespace)
The connectors renamed the variables , , and to , , and , respectively, so that they are now part of the top level namespace (e0). On the other hand, the unconnected variable, i.e., got lower level namespaces (e0e1, e0e2) as it existed in the notations of both equation 1 and equation 2. The final equation system contains five distinguishable variables (, , , , and ).
Case D: naming policy “encapsulate” without connectors
Finally, using “encapsulate without connectors results in
(equation 1, namespace: e1)
(equation 2, namespace: e2)
Now, both equations retain their individual namespaces e1 and e2. Each variable got the namespace of its original equation. The final equation system contains six distinguishable variables (, , , , , and ).
Explanation of the editor
Every connector consists of three pieces of information: The sub notation, the super notation and a variable matching list. However, there are several ways to create a connector. The standard way is to specify the sub and super notation directly and create the variable namings that need to be matched by hand. If you already have connectible elements (equations or equation systems) that you want to match, you can also load them into the connector editor. In this case, the notations and the variable namings are extracted from the loaded connected elements, which usually saves much work. The stored information, however, is still only the sub notation, the super notation and the variable matching list.
Element | Explanation |
---|---|
File | Filename of your connector once you have saved or loaded it |
Description | A description of the current connector |
Keywords | Optional keywords for your connector |
Usages | Model elements, i.e., equations or functions, in which the connector is used |
Edit Matching | Load the sub and the super notation. The variables of the sub notation will be replaced by the matches from the super notation. To connect variables from sub and super notation, add the respective variable with the “+Sub” and “+Super” buttons and match them. Do not forget to match the indices on the right side if the variables contains indices, e.g., for components |
View Notations | Take a look at all defined symbols in sub and super notation |
View Connector | See how exactly variables from the sub notation are translated into the super notation |
Test Connector | Test your connector for an arbitry model element that uses the sub notation, e.g., an equation system |