|
| 1 | +# Importing FMUs |
| 2 | + |
| 3 | +ModelingToolkit is able to import FMUs following the [FMI Standard](https://fmi-standard.org/) versions 2 and 3. |
| 4 | +This integration is done through [FMI.jl](https://github.com/ThummeTo/FMI.jl) and requires importing it to |
| 5 | +enable the relevant functionality. Currently Model Exchange (ME) and CoSimulation (CS) FMUs are supported. |
| 6 | +Events, non-floating-point variables and array variables are not supported. Additionally, calculating the |
| 7 | +time derivatives of FMU states/outputs is not supported. |
| 8 | + |
| 9 | +!!! danger "Experimental" |
| 10 | + |
| 11 | + This functionality is currently experimental and subject to change without a breaking release of |
| 12 | + ModelingToolkit.jl. |
| 13 | + |
| 14 | +## FMUs of full models |
| 15 | + |
| 16 | +Here, we will demonstrate the usage of an FMU of an entire model (as opposed to a single component). |
| 17 | +First, the required libraries must be imported and the FMU loaded using FMI.jl. |
| 18 | + |
| 19 | +```@example fmi |
| 20 | +using ModelingToolkit, FMI, FMIZoo, OrdinaryDiffEq |
| 21 | +using ModelingToolkit: t_nounits as t, D_nounits as D |
| 22 | +
|
| 23 | +# This is a spring-pendulum FMU from FMIZoo.jl. It is a v2 FMU |
| 24 | +# and we are importing it in ModelExchange format. |
| 25 | +fmu = loadFMU("SpringPendulum1D", "Dymola", "2022x"; type = :ME) |
| 26 | +``` |
| 27 | + |
| 28 | +Following are the variables in the FMU (both states and parameters): |
| 29 | + |
| 30 | +```@example fmi |
| 31 | +fmu.modelDescription.modelVariables |
| 32 | +``` |
| 33 | + |
| 34 | +Next, [`FMIComponent`](@ref) is used to import the FMU as an MTK component. We provide the FMI |
| 35 | +major version as a `Val` to the constructor, along with the loaded FMU and the type as keyword |
| 36 | +arguments. |
| 37 | + |
| 38 | +```@example fmi |
| 39 | +@named model = ModelingToolkit.FMIComponent(Val(2); fmu, type = :ME) |
| 40 | +``` |
| 41 | + |
| 42 | +Note how hierarchical names in the FMU (e.g. `mass.m` or `spring.f`) are turned into flattened |
| 43 | +names, with `__` being the namespace separator (`mass__m` and `spring__f`). |
| 44 | + |
| 45 | +!!! note |
| 46 | + |
| 47 | + Eventually we plan to reconstruct a hierarchical system structure mirroring the one indicated |
| 48 | + by the variables in the FMU. This would allow accessing the above mentioned variables as |
| 49 | + `model.mass.m` and `model.spring.f` instead of `model.mass__m` and `model.spring__f` respectively. |
| 50 | + |
| 51 | +Derivative variables such as `der(mass.v)` use the dummy derivative notation, and are hence transformed |
| 52 | +into a form similar to `mass__vˍt`. However, they can still be referred to as `D(model.mass__v)`. |
| 53 | + |
| 54 | +```@example fmi |
| 55 | +equations(model) |
| 56 | +``` |
| 57 | + |
| 58 | +Since the FMI spec allows multiple names to alias the same quantity, ModelingToolkit.jl creates |
| 59 | +equations to alias them. For example, it can be seen above that `der(mass.v)` and `mass.a` have the |
| 60 | +same reference, and hence refer to the same quantity. Correspondingly, there is an equation |
| 61 | +`mass__vˍt(t) ~ mass__a(t)` in the system. |
| 62 | + |
| 63 | +!!! note |
| 64 | + |
| 65 | + Any variables and/or parameters that are not part of the FMU should be ignored, as ModelingToolkit |
| 66 | + creates them to manage the FMU. Unexpected usage of these variables/parameters can lead to errors. |
| 67 | + |
| 68 | +```@example fmi |
| 69 | +defaults(model) |
| 70 | +``` |
| 71 | + |
| 72 | +All parameters in the FMU are given a default equal to their start value, if present. Unknowns are not |
| 73 | +assigned defaults even if a start value is present, as this would conflict with ModelingToolkit's own |
| 74 | +initialization semantics. |
| 75 | + |
| 76 | +We can simulate this model like any other ModelingToolkit system. |
| 77 | + |
| 78 | +```@repl fmi |
| 79 | +sys = structural_simplify(model) |
| 80 | +prob = ODEProblem(sys, [sys.mass__s => 0.5, sys.mass__v => 0.0], (0.0, 5.0)) |
| 81 | +sol = solve(prob, Tsit5()) |
| 82 | +``` |
| 83 | + |
| 84 | +We can interpolate the solution object to obtain values at arbitrary time points in the solved interval, |
| 85 | +just like a normal solution. |
| 86 | + |
| 87 | +```@repl fmi |
| 88 | +sol(0.0:0.1:1.0; idxs = sys.mass_a) |
| 89 | +``` |
| 90 | + |
| 91 | +FMUs following version 3 of the specification can be simulated with almost the same process. This time, |
| 92 | +we will create a model from a CoSimulation FMU. |
| 93 | + |
| 94 | +```@example fmi |
| 95 | +fmu = loadFMU("SpringPendulum1D", "Dymola", "2023x", "3.0"; type = :CS) |
| 96 | +@named inner = ModelingToolkit.FMIComponent( |
| 97 | + Val(3); fmu, communication_step_size = 0.001, type = :CS) |
| 98 | +``` |
| 99 | + |
| 100 | +This FMU has fewer equations, partly due to missing aliasing variables and partly due to being a CS FMU. |
| 101 | +CoSimulation FMUs are bundled with an integrator. As such, they do not function like ME FMUs. Instead, |
| 102 | +a callback steps the FMU at periodic intervals in time and obtains the updated state. This state is held |
| 103 | +constant until the next time the callback triggers. The periodic interval must be specified through the |
| 104 | +`communication_step_size` keyword argument. A smaller step size typically leads to less error but is |
| 105 | +more computationally expensive. |
| 106 | + |
| 107 | +This model alone does not have any differential variables, and calling `structural_simplify` will lead |
| 108 | +to an `ODESystem` with no unknowns. |
| 109 | + |
| 110 | +```@example fmi |
| 111 | +structural_simplify(inner) |
| 112 | +``` |
| 113 | + |
| 114 | +Simulating this model will cause the OrdinaryDiffEq integrator to immediately finish, and will not |
| 115 | +trigger the callback. Thus, we wrap this system in a trivial system with a differential variable. |
| 116 | + |
| 117 | +```@example fmi |
| 118 | +@variables x(t) = 1.0 |
| 119 | +@mtkbuild sys = ODESystem([D(x) ~ x], t; systems = [inner]) |
| 120 | +``` |
| 121 | + |
| 122 | +We can now simulate `sys`. |
| 123 | + |
| 124 | +```@example fmi |
| 125 | +prob = ODEProblem(sys, [sys.inner.mass__s => 0.5, sys.inner.mass__v => 0.0], (0.0, 5.0)) |
| 126 | +sol = solve(prob, Tsit5()) |
| 127 | +``` |
| 128 | + |
| 129 | +The variables of the FMU are discrete, and their timeseries can be obtained at intervals of |
| 130 | +`communication_step_size`. |
| 131 | + |
| 132 | +```@example fmi |
| 133 | +sol[sys.inner.mass__s] |
| 134 | +``` |
| 135 | + |
| 136 | +## FMUs of components |
| 137 | + |
| 138 | +FMUs can also be imported as individual components. For this example, we will use custom FMUs used |
| 139 | +in the test suite of ModelingToolkit.jl. |
| 140 | + |
| 141 | +```@example fmi |
| 142 | +fmu = loadFMU( |
| 143 | + joinpath(@__DIR__, "..", "..", "..", "test", "fmi", "fmus", "SimpleAdder.fmu"); |
| 144 | + type = :ME) |
| 145 | +fmu.modelDescription.modelVariables |
| 146 | +``` |
| 147 | + |
| 148 | +This FMU is equivalent to the following model: |
| 149 | + |
| 150 | +```julia |
| 151 | +@mtkmodel SimpleAdder begin |
| 152 | + @variables begin |
| 153 | + a(t) |
| 154 | + b(t) |
| 155 | + c(t) |
| 156 | + out(t) |
| 157 | + out2(t) |
| 158 | + end |
| 159 | + @parameters begin |
| 160 | + value = 1.0 |
| 161 | + end |
| 162 | + @equations begin |
| 163 | + out ~ a + b + value |
| 164 | + D(c) ~ out |
| 165 | + out2 ~ 2c |
| 166 | + end |
| 167 | +end |
| 168 | +``` |
| 169 | + |
| 170 | +`a` and `b` are inputs, `c` is a state, and `out` and `out2` are outputs of the component. |
| 171 | + |
| 172 | +```@repl fmi |
| 173 | +@named adder = ModelingToolkit.FMIComponent(Val(2); fmu, type = :ME); |
| 174 | +isinput(adder.a) |
| 175 | +isinput(adder.b) |
| 176 | +isoutput(adder.out) |
| 177 | +isoutput(adder.out2) |
| 178 | +``` |
| 179 | + |
| 180 | +ModelingToolkit recognizes input and output variables of the component, and attaches the appropriate |
| 181 | +metadata. We can now use this component as a subcomponent of a larger system. |
| 182 | + |
| 183 | +```@repl fmi |
| 184 | +@variables a(t) b(t) c(t) [guess = 1.0]; |
| 185 | +@mtkbuild sys = ODESystem( |
| 186 | + [adder.a ~ a, adder.b ~ b, D(a) ~ t, |
| 187 | + D(b) ~ adder.out + adder.c, c^2 ~ adder.out + adder.value], |
| 188 | + t; |
| 189 | + systems = [adder]) |
| 190 | +equations(sys) |
| 191 | +``` |
| 192 | + |
| 193 | +Note how the output `adder.out` is used in an algebraic equation of the system. We have also given |
| 194 | +`sys.c` a guess, expecting it to be solved for by initialization. ModelingToolkit is able to use |
| 195 | +FMUs in initialization to solve for initial states. As mentioned earlier, we cannot differentiate |
| 196 | +through an FMU. Thus, automatic differentiation has to be disabled for the solver. |
| 197 | + |
| 198 | +```@example fmi |
| 199 | +prob = ODEProblem(sys, [sys.adder.c => 2.0, sys.a => 1.0, sys.b => 1.0], |
| 200 | + (0.0, 1.0), [sys.adder.value => 2.0]) |
| 201 | +solve(prob, Rodas5P(autodiff = false)) |
| 202 | +``` |
| 203 | + |
| 204 | +CoSimulation FMUs follow a nearly identical process. Since CoSimulation FMUs operate using callbacks, |
| 205 | +after triggering the callbacks and altering the discrete state the algebraic equations may no longer |
| 206 | +be satisfied. To resolve for the values of algebraic variables, we use the `reinitializealg` keyword |
| 207 | +of `FMIComponent`. This is a DAE initialization algorithm to use at the end of every callback. Since |
| 208 | +CoSimulation FMUs are not directly involved in the RHS of the system - instead operating through |
| 209 | +callbacks - we can use a solver with automatic differentiation. |
| 210 | + |
| 211 | +```@example fmi |
| 212 | +fmu = loadFMU( |
| 213 | + joinpath(@__DIR__, "..", "..", "..", "test", "fmi", "fmus", "SimpleAdder.fmu"); |
| 214 | + type = :CS) |
| 215 | +@named adder = ModelingToolkit.FMIComponent( |
| 216 | + Val(2); fmu, type = :CS, communication_step_size = 1e-3, |
| 217 | + reinitializealg = BrownFullBasicInit()) |
| 218 | +@mtkbuild sys = ODESystem( |
| 219 | + [adder.a ~ a, adder.b ~ b, D(a) ~ t, |
| 220 | + D(b) ~ adder.out + adder.c, c^2 ~ adder.out + adder.value], |
| 221 | + t; |
| 222 | + systems = [adder]) |
| 223 | +prob = ODEProblem(sys, [sys.adder.c => 2.0, sys.a => 1.0, sys.b => 1.0], |
| 224 | + (0.0, 1.0), [sys.adder.value => 2.0]) |
| 225 | +solve(prob, Rodas5P()) |
| 226 | +``` |
0 commit comments