Skip to content

Commit 2035e73

Browse files
Merge pull request #3670 from AayushSabharwal/as/changelog
docs: add changelog, update docs
2 parents ac4f1c4 + 716c8aa commit 2035e73

33 files changed

+237
-139
lines changed

NEWS.md

Lines changed: 113 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# ModelingToolkit v10 Release Notes
22

3-
### Callbacks
3+
## Callbacks
44

55
Callback semantics have changed.
66

@@ -17,6 +17,118 @@ event = SymbolicDiscreteCallback(
1717
[t == 1] => [p ~ Pre(p) + 1], discrete_parameters = [p])
1818
```
1919

20+
## New `mtkcompile` and `@mtkcompile`
21+
22+
`structural_simplify` is now renamed to `mtkcompile`. `@mtkbuild` is renamed to
23+
`@mtkcompile`. Their functionality remains the same. However, instead of a second
24+
positional argument `structural_simplify(sys, (inputs, outputs))` the inputs and outputs
25+
should be specified via keyword arguments as `mtkcompile(sys; inputs, outputs, disturbance_inputs)`.
26+
27+
## Reduce reliance on metadata in `mtkcompile`
28+
29+
Previously, `mtkcompile` (formerly `structural_simplify`) used to rely on the metadata of
30+
symbolic variables to identify variables/parameters/brownians. This was regardless of
31+
what the system expected the variable to be. Now, it respects the information in the system.
32+
33+
## Unified `System` type
34+
35+
There is now a single common `System` type for all types of models except PDEs, for which
36+
`PDESystem` still exists. It follows the same syntax as `ODESystem` and `NonlinearSystem`
37+
did. `System(equations, t[, vars, pars])` will construct a time-dependent system.
38+
`System(equations[, vars, pars])` will construct a time-independent system. Refer to the
39+
docstring for `System` for further information.
40+
41+
Utility constructors are defined for:
42+
43+
- `NonlinearSystem(sys)` to convert a time-dependent system to a time-independent one for
44+
its steady state.
45+
- `SDESystem(sys, noise_eqs)` to add noise to a system
46+
- `JumpSystem(jumps, ...)` to define a system with jumps. Note that normal equations can
47+
also be passed to `jumps`.
48+
- `OptimizationSystem(cost, ...)` to define a system for optimization.
49+
50+
All problem constructors validate that the system matches the expected structure for
51+
that problem.
52+
53+
## No more `parameter_dependencies`
54+
55+
The `parameter_dependencies` keyword is deprecated. All equations previously passed here
56+
should now be provided as part of the standard equations of the system. If passing parameters
57+
explicitly to the `System` constructor, the dependent parameters (on the left hand side of
58+
parameter dependencies) should also be provided. These will be separated out when calling
59+
`complete` or `mtkcompile`. Calling `parameter_dependencies` or `dependent_parameters` now
60+
requires that the system is completed. The new `SDESystem` constructor still retains the
61+
`parameter_dependencies` keyword argument since the number of equations has to match the
62+
number of columns in `noise_eqs`.
63+
64+
ModelingToolkit now has discretion of what parameters are eliminated using the parameter
65+
equations during `complete` or `mtkcompile`.
66+
67+
## New problem and constructors
68+
69+
Instead of `XProblem(sys, u0map, tspan, pmap)` for time-dependent problems and
70+
`XProblem(sys, u0map, pmap)` for time-independent problems, the syntax has changed to
71+
`XProblem(sys, op, tspan)` and `XProblem(sys, op)` respectively. `op` refers to the
72+
operating point, and is a variable-value mapping containing both unknowns and parameters.
73+
74+
`XFunction` constructors also no longer accept the list of unknowns and parameters as
75+
positional arguments.
76+
77+
## Removed `DelayParentScope`
78+
79+
The outdated `DelayParentScope` has been removed.
80+
81+
## Removed `XProblemExpr` and `XFunctionExpr`
82+
83+
The old `XProblemExpr` and `XFunctionExpr` constructors used to build an `Expr` that
84+
constructs `XProblem` and `XFunction` respectively are now removed. This functionality
85+
is now available by passing `expression = Val{true}` to any problem or function constructor.
86+
87+
## Renaming of `generate_*` and `calculate_*` methods
88+
89+
Several `generate_*` methods have been renamed, along with some `calculate_*` methods.
90+
The `generate_*` methods also no longer accept a list of unknowns and/or parameters. Refer
91+
to the documentation for more information.
92+
93+
## New behavior of `getproperty` and `setproperty!`
94+
95+
Using `getproperty` to access fields of a system has been deprecated for a long time, and
96+
this functionality is now removed. `setproperty!` previously used to update the default
97+
of the accessed symbolic variable. This is not supported anymore. Defaults can be updated by
98+
mutating `ModelingToolkit.get_defaults(sys)`.
99+
100+
## New behavior of `@constants`
101+
102+
`@constants` now creates parameters with the `tunable = false` metadata by default.
103+
104+
## Removed `FunctionalAffect`
105+
106+
`FunctionalAffect` is now removed in favor of the new `ImperativeAffect`. Refer to the
107+
documentation for more information.
108+
109+
## Improved system metadata
110+
111+
Instead of an empty field that can contain arbitrary data, the `System` type stores metadata
112+
identically to `SymbolicUtils.BasicSymbolic`. Metadata is stored in an immutable dictionary
113+
keyed by a user-provided `DataType` and containing arbitrary values. `System` supports the
114+
same `SymbolicUtils.getmetadata` and `SymbolicUtils.setmetadata` API as symbolic variables.
115+
Refer to the documentation of `System` and the aforementioned functions for more information.
116+
117+
## Moved `connect` and `Connector` to ModelingToolkit
118+
119+
Previously ModelingToolkit used the `connect` function and `Connector` type defined in
120+
Symbolics.jl. These have now been moved to ModelingToolkit along with the experimental
121+
state machine API. If you imported them from Symbolics.jl, it is recommended to import from
122+
ModelingToolkit instead.
123+
124+
## Always wrap with `ParentScope` in `@named`
125+
126+
When creating a system using `@named`, any symbolic quantities passed as keyword arguments
127+
to the subsystem are wrapped in `ParentScope`. Previously, this would only happen if the
128+
variable wasn't already wrapped in a `ParentScope`. However, the old behavior had issues
129+
when passing symbolic quantities down multiple levels of the hierarchy. The `@named` macro
130+
now always performs this wrapping.
131+
20132
# ModelingToolkit v9 Release Notes
21133

22134
### Upgrade guide

Project.toml

Lines changed: 0 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -201,10 +201,5 @@ StochasticDiffEq = "789caeaf-c7a9-5a7d-9973-96adeb23e2a0"
201201
Sundials = "c3572dad-4567-51f8-b174-8c6c989267f4"
202202
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
203203

204-
[sources]
205-
ModelingToolkitStandardLibrary = { url = "https://github.com/SciML/ModelingToolkitStandardLibrary.jl/", rev = "mtk-v10" }
206-
OptimizationBase = { url = "https://github.com/AayushSabharwal/OptimizationBase.jl", rev = "as/mtk-v10" }
207-
OptimizationMOI = { url = "https://github.com/AayushSabharwal/Optimization.jl", subdir = "lib/OptimizationMOI", rev = "as/mtk-v10" }
208-
209204
[targets]
210205
test = ["AmplNLWriter", "BenchmarkTools", "BoundaryValueDiffEqMIRK", "BoundaryValueDiffEqAscher", "ControlSystemsBase", "DataInterpolations", "DelayDiffEq", "NonlinearSolve", "ForwardDiff", "Ipopt", "Ipopt_jll", "ModelingToolkitStandardLibrary", "Optimization", "OptimizationOptimJL", "OptimizationMOI", "OrdinaryDiffEq", "OrdinaryDiffEqCore", "OrdinaryDiffEqDefault", "REPL", "Random", "ReferenceTests", "SafeTestsets", "StableRNGs", "Statistics", "SteadyStateDiffEq", "Test", "StochasticDiffEq", "Sundials", "StochasticDelayDiffEq", "Pkg", "JET", "OrdinaryDiffEqNonlinearSolve", "Logging", "OptimizationBase"]

docs/Project.toml

Lines changed: 0 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,6 @@ BenchmarkTools = "6e4b80f9-dd63-53aa-95a3-0cdb28fa8baf"
44
BifurcationKit = "0f109fa4-8a5d-4b75-95aa-f515264e7665"
55
CairoMakie = "13f3f980-e62b-5c42-98c6-ff1f3baf88f0"
66
ControlSystemsBase = "aaaaaaaa-a6ca-5380-bf3e-84a91bcd477e"
7-
ControlSystemsMTK = "687d7614-c7e5-45fc-bfc3-9ee385575c88"
87
DataInterpolations = "82cc6244-b520-54b8-b5a6-8a565e85f1d0"
98
Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f"
109
Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"
@@ -16,9 +15,6 @@ ModelingToolkit = "961ee093-0014-501f-94e3-6117800e7a78"
1615
ModelingToolkitStandardLibrary = "16a59e39-deab-5bd0-87e4-056b12336739"
1716
NonlinearSolve = "8913a72c-1f9b-4ce2-8d82-65094dcecaec"
1817
Optim = "429524aa-4258-5aef-a3af-852621145aeb"
19-
Optimization = "7f7a1694-90dd-40f0-9382-eb1efda571ba"
20-
OptimizationBase = "bca83a33-5cc9-4baa-983d-23429ab6bcbb"
21-
OptimizationOptimJL = "36348300-93cb-4f02-beb5-3c3902f8871e"
2218
OrdinaryDiffEq = "1dea7af3-3e70-54e6-95c3-0bf5283fa5ed"
2319
Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"
2420
PreallocationTools = "d236fae5-4411-538c-8e31-a6e3d9e00b46"
@@ -30,10 +26,6 @@ SymbolicUtils = "d1185830-fcd6-423d-90d6-eec64667417b"
3026
Symbolics = "0c5d862f-8b57-4792-8d23-62f2024744c7"
3127
Unitful = "1986cc42-f94f-5a68-af5c-568840ba703d"
3228

33-
[sources]
34-
ModelingToolkitStandardLibrary = {rev = "mtk-v10", url = "https://github.com/SciML/ModelingToolkitStandardLibrary.jl/"}
35-
OptimizationBase = {rev = "as/mtk-v10", url = "https://github.com/AayushSabharwal/OptimizationBase.jl"}
36-
3729
[compat]
3830
Attractors = "1.24"
3931
BenchmarkTools = "1.3"
@@ -49,8 +41,6 @@ ModelingToolkit = "10"
4941
ModelingToolkitStandardLibrary = "2.19"
5042
NonlinearSolve = "3, 4"
5143
Optim = "1.7"
52-
Optimization = "3.9, 4"
53-
OptimizationOptimJL = "0.1, 0.4"
5444
OrdinaryDiffEq = "6.31"
5545
Plots = "1.36"
5646
PreallocationTools = "0.4"

docs/src/API/variables.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ When variables with descriptions are present in systems, they will be printed wh
3434
```@example metadata
3535
@variables u(t) [description = "A short description of u"]
3636
@parameters p [description = "A description of p"]
37-
@named sys = ODESystem([u ~ p], t)
37+
@named sys = System([u ~ p], t)
3838
show(stdout, "text/plain", sys) # hide
3939
```
4040

@@ -298,7 +298,7 @@ In the example below, we define a system with tunable parameters and extract bou
298298
@parameters k [tunable = true, bounds = (0, Inf)]
299299
eqs = [D(x) ~ (-x + k * u) / T # A first-order system with time constant T and gain k
300300
y ~ x]
301-
sys = ODESystem(eqs, t, name = :tunable_first_order)
301+
sys = System(eqs, t, name = :tunable_first_order)
302302
```
303303

304304
```@example metadata

docs/src/basics/AbstractSystem.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ model manipulation and compilation.
1212
There are three immediate subtypes of `AbstractSystem`, classified by how many independent variables each type has:
1313

1414
- `AbstractTimeIndependentSystem`: has no independent variable (e.g.: `NonlinearSystem`)
15-
- `AbstractTimeDependentSystem`: has a single independent variable (e.g.: `ODESystem`)
15+
- `AbstractTimeDependentSystem`: has a single independent variable (e.g.: `System`)
1616
- `AbstractMultivariateSystem`: may have multiple independent variables (e.g.: `PDESystem`)
1717

1818
## Constructors and Naming

docs/src/basics/Composition.md

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ using ModelingToolkit: t_nounits as t, D_nounits as D
2121
function decay(; name)
2222
@parameters a
2323
@variables x(t) f(t)
24-
ODESystem([
24+
System([
2525
D(x) ~ -a * x + f
2626
], t;
2727
name = name)
@@ -31,7 +31,7 @@ end
3131
@named decay2 = decay()
3232
3333
connected = compose(
34-
ODESystem([decay2.f ~ decay1.x
34+
System([decay2.f ~ decay1.x
3535
D(decay1.f) ~ 0], t; name = :connected), decay1, decay2)
3636
3737
equations(connected)
@@ -69,7 +69,7 @@ subsystems. A model is the composition of itself and its subsystems.
6969
For example, if we have:
7070

7171
```julia
72-
@named sys = compose(ODESystem(eqs, indepvar, unknowns, ps), subsys)
72+
@named sys = compose(System(eqs, indepvar, unknowns, ps), subsys)
7373
```
7474

7575
the `equations` of `sys` is the concatenation of `get_eqs(sys)` and
@@ -122,7 +122,7 @@ With symbolic parameters, it is possible to set the default value of a parameter
122122

123123
```julia
124124
# ...
125-
sys = ODESystem(
125+
sys = System(
126126
# ...
127127
# directly in the defaults argument
128128
defaults = Pair{Num, Any}[x => u,
@@ -144,20 +144,20 @@ d = GlobalScope(d)
144144

145145
p = [a, b, c, d]
146146

147-
level0 = ODESystem(Equation[], t, [], p; name = :level0)
148-
level1 = ODESystem(Equation[], t, [], []; name = :level1) level0
147+
level0 = System(Equation[], t, [], p; name = :level0)
148+
level1 = System(Equation[], t, [], []; name = :level1) level0
149149
parameters(level1)
150150
#level0₊a
151151
#b
152152
#c
153153
#d
154-
level2 = ODESystem(Equation[], t, [], []; name = :level2) level1
154+
level2 = System(Equation[], t, [], []; name = :level2) level1
155155
parameters(level2)
156156
#level1₊level0₊a
157157
#level1₊b
158158
#c
159159
#d
160-
level3 = ODESystem(Equation[], t, [], []; name = :level3) level2
160+
level3 = System(Equation[], t, [], []; name = :level3) level2
161161
parameters(level3)
162162
#level2₊level1₊level0₊a
163163
#level2₊level1₊b
@@ -194,12 +194,12 @@ using ModelingToolkit: t_nounits as t, D_nounits as D
194194
N = S + I + R
195195
@parameters β, γ
196196
197-
@named seqn = ODESystem([D(S) ~ -β * S * I / N], t)
198-
@named ieqn = ODESystem([D(I) ~ β * S * I / N - γ * I], t)
199-
@named reqn = ODESystem([D(R) ~ γ * I], t)
197+
@named seqn = System([D(S) ~ -β * S * I / N], t)
198+
@named ieqn = System([D(I) ~ β * S * I / N - γ * I], t)
199+
@named reqn = System([D(R) ~ γ * I], t)
200200
201201
sir = compose(
202-
ODESystem(
202+
System(
203203
[
204204
S ~ ieqn.S,
205205
I ~ seqn.I,
@@ -266,6 +266,6 @@ equations are discontinuous in either the unknown or one of its derivatives. Thi
266266
causes the solver to take very small steps around the discontinuity, and
267267
sometimes leads to early stopping due to `dt <= dt_min`. The correct way to
268268
handle such dynamics is to tell the solver about the discontinuity by a
269-
root-finding equation, which can be modeling using [`ODESystem`](@ref)'s event
269+
root-finding equation, which can be modeling using [`System`](@ref)'s event
270270
support. Please see the tutorial on [Callbacks and Events](@ref events) for
271271
details and examples.

docs/src/basics/Debugging.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ using ModelingToolkit: t_nounits as t, D_nounits as D
1212
@variables u1(t) u2(t) u3(t)
1313
eqs = [D(u1) ~ -√(u1), D(u2) ~ -√(u2), D(u3) ~ -√(u3)]
1414
defaults = [u1 => 1.0, u2 => 2.0, u3 => 3.0]
15-
@named sys = ODESystem(eqs, t; defaults)
15+
@named sys = System(eqs, t; defaults)
1616
sys = mtkcompile(sys)
1717
```
1818

@@ -38,7 +38,7 @@ We could have figured that out ourselves, but it is not always so obvious for mo
3838
Suppose we also want to validate that `u1 + u2 >= 2.0`. We can do this via the assertions functionality.
3939

4040
```@example debug
41-
@mtkcompile sys = ODESystem(eqs, t; defaults, assertions = [(u1 + u2 >= 2.0) => "Oh no!"])
41+
@mtkcompile sys = System(eqs, t; defaults, assertions = [(u1 + u2 >= 2.0) => "Oh no!"])
4242
```
4343

4444
The assertions must be an iterable of pairs, where the first element is the symbolic condition and

0 commit comments

Comments
 (0)