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
where, `affect!` is a Julia function with the signature: `affect!(integ, u, p, ctx)`; `[u,v]` and `[p,q]` are the symbolic unknowns (variables) and parameters
151
-
that are accessed by `affect!`, respectively; and `ctx` is any context that is
152
-
passed to `affect!` as the `ctx` argument.
151
+
that are accessed by `affect!`, respectively; `discretes` are the parameters modified by `affect!`, if any;
152
+
and `ctx` is any context that is passed to `affect!` as the `ctx` argument.
Example usage below. Note that `ModelingToolkit` does not force unit conversions to preferred units in the event of nonstandard combinations -- it merely checks that the equations are consistent.
An example of an inconsistent system: at present, `ModelingToolkit` requires that the units of all terms in an equation or sum to be equal-valued (`ModelingToolkit.equivalent(u1,u2)`), rather than simply dimensionally consistent. In the future, the validation stage may be upgraded to support the insertion of conversion factors into the equations.
sys = ODESystem(eqs, t, [sts...;], [ps...;], name = :sys)
107
+
sys = ODESystem(
108
+
eqs, t, [sts...;], [ps...;], name = :sys, checks = ~ModelingToolkit.CheckUnits)
105
109
sys_simple = structural_simplify(sys)
106
110
```
107
111
108
-
## `Unitful` Literals
112
+
## `DynamicQuantities` Literals
109
113
110
114
In order for a function to work correctly during both validation & execution, the function must be unit-agnostic. That is, no unitful literals may be used. Any unitful quantity must either be a `parameter` or `variable`. For example, these equations will not validate successfully.
111
115
112
116
```julia
113
-
using ModelingToolkit, Unitful
117
+
using ModelingToolkit, DynamicQuantities
114
118
@variables t [unit =u"ms"] E(t) [unit =u"J"] P(t) [unit =u"MW"]
115
119
D =Differential(t)
116
120
eqs = [D(E) ~ P - E /1u"ms"]
@@ -124,7 +128,7 @@ ModelingToolkit.validate(eqs) #Returns false while displaying a warning message
It is recommended *not* to circumvent unit validation by specializing user-defined functions on `Unitful` arguments vs. `Numbers`. This both fails to take advantage of `validate` for ensuring correctness, and may cause in errors in the
142
-
future when `ModelingToolkit` is extended to support eliminating `Unitful` literals from functions.
145
+
It is recommended *not* to circumvent unit validation by specializing user-defined functions on `DynamicQuantities` arguments vs. `Numbers`. This both fails to take advantage of `validate` for ensuring correctness, and may cause in errors in the
146
+
future when `ModelingToolkit` is extended to support eliminating `DynamicQuantities` literals from functions.
143
147
144
148
## Other Restrictions
145
149
@@ -149,7 +153,7 @@ future when `ModelingToolkit` is extended to support eliminating `Unitful` liter
149
153
150
154
If a system fails to validate due to unit issues, at least one warning message will appear, including a line number as well as the unit types and expressions that were in conflict. Some system constructors re-order equations before the unit checking can be done, in which case the equation numbers may be inaccurate. The printed expression that the problem resides in is always correctly shown.
151
155
152
-
Symbolic exponents for unitful variables *are* supported (ex: `P^γ` in thermodynamics). However, this means that `ModelingToolkit` cannot reduce such expressions to `Unitful.Unitlike` subtypes at validation time because the exponent value is not available. In this case `ModelingToolkit.get_unit` is type-unstable, yielding a symbolic result, which can still be checked for symbolic equality with `ModelingToolkit.equivalent`.
156
+
Symbolic exponents for unitful variables *are* supported (ex: `P^γ` in thermodynamics). However, this means that `ModelingToolkit` cannot reduce such expressions to `DynamicQuantities.Quantity` subtypes at validation time because the exponent value is not available. In this case `ModelingToolkit.get_unit` is type-unstable, yielding a symbolic result, which can still be checked for symbolic equality with `ModelingToolkit.equivalent`.
Copy file name to clipboardExpand all lines: docs/src/internals.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,6 @@ The call chain typically looks like this, with the function names in the case of
32
32
33
33
1. Problem constructor ([`ODEProblem`](@ref))
34
34
2. Build an `DEFunction` ([`process_DEProblem`](@ref) -> [`ODEFunction`](@ref)
35
-
3. Write actual executable code ([`generate_function`](@ref))
35
+
3. Write actual executable code ([`generate_function`](@ref) or [`generate_custom_function`](@ref))
36
36
37
37
Apart from [`generate_function`](@ref), which generates the dynamics function, `ODEFunction` also builds functions for observed equations (`build_explicit_observed_function`) and Jacobians (`generate_jacobian`) etc. These are all stored in the `ODEFunction`.
Copy file name to clipboardExpand all lines: docs/src/tutorials/domain_connections.md
+1-39
Original file line number
Diff line number
Diff line change
@@ -94,7 +94,7 @@ end
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.
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.
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.
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.
Copy file name to clipboardExpand all lines: docs/src/tutorials/optimization.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -6,13 +6,13 @@ Let's solve the classical _Rosenbrock function_ in two dimensions.
6
6
7
7
First, we need to make some imports.
8
8
9
-
```@example rosenbrock_2d
9
+
```julia
10
10
using ModelingToolkit, Optimization, OptimizationOptimJL
11
11
```
12
12
13
13
Now we can define our optimization problem.
14
14
15
-
```@example rosenbrock_2d
15
+
```julia
16
16
@variablesbegin
17
17
x, [bounds = (-2.0, 2.0)]
18
18
y, [bounds = (-1.0, 3.0)]
@@ -44,7 +44,7 @@ Every optimization problem consists of a set of _optimization variables_. In thi
44
44
45
45
Next, the actual `OptimizationProblem` can be created. At this stage, an initial guess `u0` for the optimization variables needs to be provided via map, using the symbols from before. Concrete values for the parameters of the system can also be provided or changed. However, if the parameters have default values assigned, they are used automatically.
46
46
47
-
```@example rosenbrock_2d
47
+
```julia
48
48
u0 = [x =>1.0
49
49
y =>2.0]
50
50
p = [a =>1.0
@@ -56,7 +56,7 @@ solve(prob, GradientDescent())
56
56
57
57
## Rosenbrock Function with Constraints
58
58
59
-
```@example rosenbrock_2d_cstr
59
+
```julia
60
60
using ModelingToolkit, Optimization, OptimizationOptimJL
0 commit comments