|
94 | 94 | nothing #hide
|
95 | 95 | ```
|
96 | 96 |
|
97 |
| -When the system is defined we can generate a fluid component and connect it to the system. Here `fluid` is connected to the `src.port`, but it could also be connected to `vol.port`, any connection in the network is fine. Note: we can visualize the system using `ModelingToolkitDesigner.jl`, where a dashed line is used to show the `fluid` connection to represent a domain connection that is only transporting parameters and not unknown variables. |
| 97 | +When the system is defined we can generate a fluid component and connect it to the system. Here `fluid` is connected to the `src.port`, but it could also be connected to `vol.port`, any connection in the network is fine. |
98 | 98 |
|
99 | 99 | ```@example domain
|
100 | 100 | @component function System(; name)
|
|
115 | 115 | nothing #hide
|
116 | 116 | ```
|
117 | 117 |
|
118 |
| -```@setup domain |
119 |
| -# code to generate diagrams... |
120 |
| -# using ModelingToolkitDesigner |
121 |
| -# path = raw"C:\Work\Assets\ModelingToolkit.jl\domain_connections" |
122 |
| -# design = ODESystemDesign(odesys, path); |
123 |
| -
|
124 |
| -# using CairoMakie |
125 |
| -# CairoMakie.set_theme!(Theme(;fontsize=12)) |
126 |
| -# fig = ModelingToolkitDesigner.view(design, false) |
127 |
| -# save(joinpath(path, "odesys.svg"), fig; resolution=(300,300)) |
128 |
| -``` |
129 |
| - |
130 |
| - |
131 |
| - |
132 | 118 | To see how the domain works, we can examine the set parameter values for each of the ports `src.port` and `vol.port`. First we assemble the system using `structural_simplify()` and then check the default value of `vol.port.ρ`, whichs points to the setter value `fluid₊ρ`. Likewise, `src.port.ρ`, will also point to the setter value `fluid₊ρ`. Therefore, there is now only 1 defined density value `fluid₊ρ` which sets the density for the connected network.
|
133 | 119 |
|
134 | 120 | ```@repl domain
|
|
195 | 181 | nothing #hide
|
196 | 182 | ```
|
197 | 183 |
|
198 |
| -```@setup domain |
199 |
| -# design = ODESystemDesign(actsys2, path); |
200 |
| -# fig = ModelingToolkitDesigner.view(design, false) |
201 |
| -# save(joinpath(path, "actsys2.svg"), fig; resolution=(500,300)) |
202 |
| -``` |
203 |
| - |
204 |
| - |
205 |
| - |
206 | 184 | After running `structural_simplify()` on `actsys2`, the defaults will show that `act.port_a.ρ` points to `fluid_a₊ρ` and `act.port_b.ρ` points to `fluid_b₊ρ`. This is a special case, in most cases a hydraulic system will have only 1 fluid, however this simple system has 2 separate domain networks. Therefore, we can connect a single fluid to both networks. This does not interfere with the mathematical equations of the system, since no unknown variables are connected.
|
207 | 185 |
|
208 | 186 | ```@example domain
|
|
227 | 205 | nothing #hide
|
228 | 206 | ```
|
229 | 207 |
|
230 |
| -```@setup domain |
231 |
| -# design = ODESystemDesign(actsys1, path); |
232 |
| -# fig = ModelingToolkitDesigner.view(design, false) |
233 |
| -# save(joinpath(path, "actsys1.svg"), fig; resolution=(500,300)) |
234 |
| -``` |
235 |
| - |
236 |
| - |
237 |
| - |
238 | 208 | ## Special Connection Cases (`domain_connect()`)
|
239 | 209 |
|
240 | 210 | In some cases a component will be defined with 2 connectors of the same domain, but they are not connected. For example the `Restrictor` defined here gives equations to define the behavior of how the 2 connectors `port_a` and `port_b` are physically connected.
|
|
282 | 252 | nothing #hide
|
283 | 253 | ```
|
284 | 254 |
|
285 |
| -```@setup domain |
286 |
| -# design = ODESystemDesign(ressys, path); |
287 |
| -# fig = ModelingToolkitDesigner.view(design, false) |
288 |
| -# save(joinpath(path, "ressys.svg"), fig; resolution=(500,300)) |
289 |
| -``` |
290 |
| - |
291 |
| - |
292 |
| - |
293 | 255 | When `structural_simplify()` is applied to this system it can be seen that the defaults are missing for `res.port_b` and `vol.port`.
|
294 | 256 |
|
295 | 257 | ```@repl domain
|
|
0 commit comments