You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/connectors/connections.md
+21-21Lines changed: 21 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,17 @@
1
1
# Introduction
2
2
3
-
In Physical Network Acausal modeling each physical domain must define a **connector** to combine model components. Each physical domain **connector** defines a minimum of 2 variables, one which is called a *Through* variable, and one which is called an *Across* variable. Both Modelica and SimScape define these variables in the same way:
3
+
In Physical Network Acausal modeling, each physical domain must define a **connector** to combine model components. Each physical domain **connector** defines a minimum of 2 variables, one which is called a *Through* variable, and one which is called an *Across* variable. Both Modelica and SimScape define these variables in the same way:
However, the standard libraries differ on the selection of the Across variable for the Mechanical Translation and Rotation libraries, Modelica choosing position and angle and SimScape choosing velocity and angular velocity, respectively for Translation and Rotation. Modelica describes their decision [here](https://mbe.modelica.university/components/connectors/simple_domains/). In summary they would like to provide less integration in the model to avoid lossy numerical behavior, but this decision assumes the lowest order derivative is needed by the model. Numerically it is possible to define the connector either way, but there are some consequences to this decision, and therefore we will study them in detail here as they relate to ModelingToolkit.
8
+
However, the standard libraries differ on the selection of the Across variable for the Mechanical Translation and Rotation libraries, Modelica choosing position and angle and SimScape choosing velocity and angular velocity, respectively for Translation and Rotation. Modelica describes their decision [here](https://mbe.modelica.university/components/connectors/simple_domains/). In summary, they would like to provide less integration in the model to avoid lossy numerical behavior, but this decision assumes the lowest order derivative is needed by the model. Numerically it is possible to define the connector either way, but there are some consequences of this decision, and therefore we will study them in detail here as they relate to ModelingToolkit.
9
9
10
10
# Through and Across Variable Theory
11
11
12
12
### General
13
13
14
-
The idea behind the selection of the **through** variable is that it should be a time derivative of some conserved quantity. The conserved quantity should be expressed by the **across** variable. In general terms the physical system is given by
14
+
The idea behind the selection of the **through** variable is that it should be a time derivative of some conserved quantity. The conserved quantity should be expressed by the **across** variable. In general terms, the physical system is given by
15
15
16
16
- Energy Dissipation & Flow:
17
17
@@ -24,7 +24,7 @@ The idea behind the selection of the **through** variable is that it should be a
24
24
25
25
### Electrical
26
26
27
-
For the Electrical domain the across variable is *voltage* and the through variable *current*. Therefore
27
+
For the Electrical domain, the across variable is *voltage* and the through variable *current*. Therefore
28
28
29
29
- Energy Dissipation:
30
30
@@ -60,7 +60,7 @@ The diagram here shows the similarity of problems in different physical domains.
60
60
61
61
### Translational Connector using *Position* Across Variable
62
62
63
-
Now, if we choose *position* for the across variable, a similar relationship can be established, but the patern must be broken.
63
+
Now, if we choose *position* for the across variable, a similar relationship can be established, but the pattern must be broken.
64
64
65
65
- Energy Dissipation:
66
66
@@ -109,7 +109,7 @@ println.(equations(sys))
109
109
nothing # hide
110
110
```
111
111
112
-
The solution shows what we would expect, a non-linear disipation of voltage and releated decrease in current flow...
112
+
The solution shows what we would expect, a non-linear dissipation of voltage and related decrease in current flow…
113
113
114
114
```@example connections
115
115
prob = ODEProblem(sys, [1.0], (0, 10.0), [])
@@ -149,7 +149,7 @@ println.(full_equations(sys))
149
149
nothing # hide
150
150
```
151
151
152
-
As expected we have a similar solution...
152
+
As expected, we have a similar solution…
153
153
154
154
```@example connections
155
155
prob = ODEProblem(sys, [], (0, 10.0), [])
@@ -162,7 +162,7 @@ plot(p1, p2)
162
162
163
163
#### Across Variable = position
164
164
165
-
Now, let's consider the positionbased approach. We can build the same model with the same components. As can be seen, we now end of up with 2 equations, because we need to relate the lower derivative (position) to force (with acceleration).
165
+
Now, let's consider the position-based approach. We can build the same model with the same components. As can be seen, we now end of up with 2 equations, because we need to relate the lower derivative (position) to force (with acceleration).
The question then arises, can the position be plotted when using the Mechanical Translational Domain based on the Velocity Across variable? Yes, we can! There are 2 solutions:
199
199
200
-
1. the `Mass` component will add the position variable when the `s_0` parameter is used to set an initial position. Otherwise the position is not tracked by the component.
200
+
1. the `Mass` component will add the position variable when the `s_0` parameter is used to set an initial position. Otherwise, the component does not track the position.
201
201
202
202
```julia
203
203
@named body = TV.Mass(m =1, v_0 =1, s_0 =0)
@@ -212,15 +212,15 @@ Either option will produce the same result regardless of which across variable i
212
212
213
213
## Initialization
214
214
215
-
The main difference between `ModelingToolkitStandardLibrary.Mechanical.Translational` and `ModelingToolkitStandardLibrary.Mechanical.TranslationalPosition` is how they are initialized. In the `ModelingToolkitStandardLibrary` initialization parameters are defined at the component level, so we simply need to be careful to set the correct initial conditions for the domain that it used. Let's use the following example problem to explain the differences.
215
+
The main difference between `ModelingToolkitStandardLibrary.Mechanical.Translational` and `ModelingToolkitStandardLibrary.Mechanical.TranslationalPosition` is how they are initialized. In the `ModelingToolkitStandardLibrary` initialization, parameters are defined at the component level, so we simply need to be careful to set the correct initial conditions for the domain that it used. Let's use the following example problem to explain the differences.
216
216
217
217
218
218
219
-
In this problem we have a mass, spring, and damper which are connected to a fixed point. Let's see how each component is defined.
219
+
In this problem, we have a mass, spring, and damper which are connected to a fixed point. Let's see how each component is defined.
220
220
221
221
#### Damper
222
222
223
-
The damper will connect the flange/flange 1 (`flange_a`) to the mass, and flange/flange 2 (`flange_b`) to the fixed point. For both position and velocitybased domains, we set the damping constant `d=1` and `v_a_0=1` and leave the default for `v_b_0` at 0. For the position domain we also need to set the initial positions for `flange_a` and `flange_b`.
223
+
The damper will connect the flange/flange 1 (`flange_a`) to the mass, and flange/flange 2 (`flange_b`) to the fixed point. For both position- and velocity-based domains, we set the damping constant `d=1` and `v_a_0=1` and leave the default for `v_b_0` at 0. For the position domain, we also need to set the initial positions for `flange_a` and `flange_b`.
224
224
225
225
```@example connections
226
226
@named dv = TV.Damper(d = 1, v_a_0 = 1)
@@ -230,7 +230,7 @@ nothing # hide
230
230
231
231
#### Spring
232
232
233
-
The spring will connect the flange/flange 1 (`flange_a`) to the mass, and flange/flange 2 (`flange_b`) to the fixed point. For both position and velocitybased domains, we set the spring constant `k=1`. The velocity domain then requires the initial velocity `v_a_0` and initial spring stretch `delta_s_0`. The position domain instead needs the initial positions for `flange_a` and `flange_b` and the natural spring length `l`.
233
+
The spring will connect the flange/flange 1 (`flange_a`) to the mass, and flange/flange 2 (`flange_b`) to the fixed point. For both position- and velocity-based domains, we set the spring constant `k=1`. The velocity domain then requires the initial velocity `v_a_0` and initial spring stretch `delta_s_0`. The position domain instead needs the initial positions for `flange_a` and `flange_b` and the natural spring length `l`.
For both position and velocitybased domains, we set the mass `m=1` and initial velocity `v_0=1`. Like the damper, the position domain requires the position initial conditions set as well.
243
+
For both position- and velocity-based domains, we set the mass `m=1` and initial velocity `v_0=1`. Like the damper, the position domain requires the position initial conditions set as well.
244
244
245
245
```@example connections
246
246
@named bv = TV.Mass(m = 1, v_0 = 1)
@@ -250,7 +250,7 @@ nothing # hide
250
250
251
251
#### Fixed
252
252
253
-
Here the velocity domain requires no initial condition, but for our model to work as defined we must set the position domain component to the correct intital position.
253
+
Here the velocity domain requires no initial condition, but for our model to work as defined we must set the position domain component to the correct initial position.
254
254
255
255
```@example connections
256
256
@named gv = TV.Fixed()
@@ -260,9 +260,9 @@ nothing # hide
260
260
261
261
### Comparison
262
262
263
-
As can be seen, the positionbased domain requires more initial condition information to be properly defined since the absolute position information is required. Thereore based on the model being described, it may be more natural to choose one domain over the other.
263
+
As can be seen, the position-based domain requires more initial condition information to be properly defined, since the absolute position information is required. Therefore, based on the model being described, it may be more natural to choose one domain over the other.
264
264
265
-
Let's define a quick function to simplify and solve the 2 different systems. Note we will solve with a fixed time step and a set tolerance to compare the numerical differences.
265
+
Let's define a quick function to simplify and solve the 2 different systems. Note, we will solve with a fixed time step and a set tolerance to compare the numerical differences.
266
266
267
267
```@example connections
268
268
function simplify_and_solve(damping, spring, body, ground)
@@ -305,7 +305,7 @@ plot!(solv, idxs = [bv.v])
305
305
plot!(solp, idxs = [bp.v])
306
306
```
307
307
308
-
But, what if we wanted to plot the mass position? This is easy for the positionbased domain, we have the state `bp₊s(t)`, but for the velocitybased domain we have `sv₊delta_s(t)` which is the spring stretch. To get the absolute position we add the spring natrual length (1m) and the fixed position (1m). As can be seen, we then get the same result.
308
+
But, what if we wanted to plot the mass position? This is easy for the position-based domain, we have the state `bp₊s(t)`, but for the velocity-based domain we have `sv₊delta_s(t)` which is the spring stretch. To get the absolute position, we add the spring natural length (1m) and the fixed position (1m). As can be seen, we then get the same result.
309
309
310
310
```@example connections
311
311
plot(ylabel = "mass position [m]")
@@ -315,9 +315,9 @@ plot!(solp, idxs = [bp.s])
315
315
316
316
So in conclusion, the position based domain gives easier access to absolute position information, but requires more initial condition information.
317
317
318
-
## Acuracy
318
+
## Accuracy
319
319
320
-
One may ask then what is the tradeoff in terms of numerical acuracy? When we look at the simplified equations, we can see that actually both systems solve the same equations. The differential equations of the velocity domain are
320
+
One may then ask, what the trade-off in terms of numerical accuracy is. When we look at the simplified equations, we can see that actually both systems solve the same equations. The differential equations of the velocity domain are
321
321
322
322
```math
323
323
\begin{aligned}
@@ -335,7 +335,7 @@ m \cdot \dot{v} + d \cdot v + k \cdot (s - s_{b_0} - l) = 0 \\
The electrical part consists of a resistance and inductance. The coupling between the electrical and rotational domain is done via an electromotive force (EMF) component. The voltage across the EMF is proportional to the angular velocity and the current is proportional to the torque. On the mechanical side viscous friction in e.g. a bearing and the inertia of the shaft is modelled.
9
+
The electrical part consists of a resistance and inductance. The coupling between the electrical and rotational domain is done via an electro-motive force (EMF) component. The voltage across the EMF is proportional to the angular velocity and the current is proportional to the torque. On the mechanical side, viscous friction in, e.g., a bearing and the inertia of the shaft is modelled.
10
10
11
-
A PI-controller with antiwindup measure should be used as a speed controller. A simulation is performed to verify the tracking performance of the controller and the disturbance rejection capabilities.
11
+
A PI-controller with anti-windup measure should be used as a speed controller. A simulation is performed to verify the tracking performance of the controller and the disturbance rejection capabilities.
12
12
13
-
First the needed packages are imported and the parameters of the model defined.
13
+
First, the needed packages are imported and the parameters of the model defined.
14
14
15
15
```@example dc_motor_pi
16
16
using ModelingToolkit
@@ -84,7 +84,7 @@ nothing # hide
84
84
```
85
85
86
86
Now the model can be simulated. Typical rotational mechanical systems are described via `DAE`
87
-
(differential algebraic equations), however in this case ModelingToolkit can simplify the model enough
87
+
(differential algebraic equations), however in this case, ModelingToolkit can simplify the model enough
88
88
so that it can be represented as a system of `ODEs` (ordinary differential equations).
0 commit comments