|
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