From 0111aa6f65139e2a48fc68fec8fb3585a300b714 Mon Sep 17 00:00:00 2001 From: Aayush Sabharwal Date: Wed, 28 May 2025 23:22:32 +0530 Subject: [PATCH 1/6] docs: add v10 release notes to `NEWS.md` --- NEWS.md | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 113 insertions(+), 1 deletion(-) diff --git a/NEWS.md b/NEWS.md index d316ac23fb..726bf1628f 100644 --- a/NEWS.md +++ b/NEWS.md @@ -1,6 +1,6 @@ # ModelingToolkit v10 Release Notes -### Callbacks +## Callbacks Callback semantics have changed. @@ -17,6 +17,118 @@ event = SymbolicDiscreteCallback( [t == 1] => [p ~ Pre(p) + 1], discrete_parameters = [p]) ``` +## New `mtkcompile` and `@mtkcompile` + +`structural_simplify` is now renamed to `mtkcompile`. `@mtkbuild` is renamed to +`@mtkcompile`. Their functionality remains the same. However, instead of a second +positional argument `structural_simplify(sys, (inputs, outputs))` the inputs and outputs +should be specified via keyword arguments as `mtkcompile(sys; inputs, outputs, disturbance_inputs)`. + +## Reduce reliance on metadata in `mtkcompile` + +Previously, `mtkcompile` (formerly `structural_simplify`) used to rely on the metadata of +symbolic variables to identify variables/parameters/brownians. This was regardless of +what the system expected the variable to be. Now, it respects the information in the system. + +## Unified `System` type + +There is now a single common `System` type for all types of models except PDEs, for which +`PDESystem` still exists. It follows the same syntax as `ODESystem` and `NonlinearSystem` +did. `System(equations, t[, vars, pars])` will construct a time-dependent system. +`System(equations[, vars, pars])` will construct a time-independent system. Refer to the +docstring for `System` for further information. + +Utility constructors are defined for: + + - `NonlinearSystem(sys)` to convert a time-dependent system to a time-independent one for + its steady state. + - `SDESystem(sys, noise_eqs)` to add noise to a system + - `JumpSystem(jumps, ...)` to define a system with jumps. Note that normal equations can + also be passed to `jumps`. + - `OptimizationSystem(cost, ...)` to define a system for optimization. + +All problem constructors validate that the system matches the expected structure for +that problem. + +## No more `parameter_dependencies` + +The `parameter_dependencies` keyword is deprecated. All equations previously passed here +should now be provided as part of the standard equations of the system. If passing parameters +explicitly to the `System` constructor, the dependent parameters (on the left hand side of +parameter dependencies) should also be provided. These will be separated out when calling +`complete` or `mtkcompile`. Calling `parameter_dependencies` or `dependent_parameters` now +requires that the system is completed. The new `SDESystem` constructor still retains the +`parameter_dependencies` keyword argument since the number of equations has to match the +number of columns in `noise_eqs`. + +ModelingToolkit now has discretion of what parameters are eliminated using the parameter +equations during `complete` or `mtkcompile`. + +## New problem and constructors + +Instead of `XProblem(sys, u0map, tspan, pmap)` for time-dependent problems and +`XProblem(sys, u0map, pmap)` for time-independent problems, the syntax has changed to +`XProblem(sys, op, tspan)` and `XProblem(sys, op)` respectively. `op` refers to the +operating point, and is a variable-value mapping containing both unknowns and parameters. + +`XFunction` constructors also no longer accept the list of unknowns and parameters as +positional arguments. + +## Removed `DelayParentScope` + +The outdated `DelayParentScope` has been removed. + +## Removed `XProblemExpr` and `XFunctionExpr` + +The old `XProblemExpr` and `XFunctionExpr` constructors used to build an `Expr` that +constructs `XProblem` and `XFunction` respectively are now removed. This functionality +is now available by passing `expression = Val{true}` to any problem or function constructor. + +## Renaming of `generate_*` and `calculate_*` methods + +Several `generate_*` methods have been renamed, along with some `calculate_*` methods. +The `generate_*` methods also no longer accept a list of unknowns and/or parameters. Refer +to the documentation for more information. + +## New behavior of `getproperty` and `setproperty!` + +Using `getproperty` to access fields of a system has been deprecated for a long time, and +this functionality is now removed. `setproperty!` previously used to update the default +of the accessed symbolic variable. This is not supported anymore. Defaults can be updated by +mutating `ModelingToolkit.get_defaults(sys)`. + +## New behavior of `@constants` + +`@constants` now creates parameters with the `tunable = false` metadata by default. + +## Removed `FunctionalAffect` + +`FunctionalAffect` is now removed in favor of the new `ImperativeAffect`. Refer to the +documentation for more information. + +## Improved system metadata + +Instead of an empty field that can contain arbitrary data, the `System` type stores metadata +identically to `SymbolicUtils.BasicSymbolic`. Metadata is stored in an immutable dictionary +keyed by a user-provided `DataType` and containing arbitrary values. `System` supports the +same `SymbolicUtils.getmetadata` and `SymbolicUtils.setmetadata` API as symbolic variables. +Refer to the documentation of `System` and the aforementioned functions for more information. + +## Moved `connect` and `Connector` to ModelingToolkit + +Previously ModelingToolkit used the `connect` function and `Connector` type defined in +Symbolics.jl. These have now been moved to ModelingToolkit along with the experimental +state machine API. If you imported them from Symbolics.jl, it is recommended to import from +ModelingToolkit instead. + +## Always wrap with `ParentScope` in `@named` + +When creating a system using `@named`, any symbolic quantities passed as keyword arguments +to the subsystem are wrapped in `ParentScope`. Previously, this would only happen if the +variable wasn't already wrapped in a `ParentScope`. However, the old behavior had issues +when passing symbolic quantities down multiple levels of the hierarchy. The `@named` macro +now always performs this wrapping. + # ModelingToolkit v9 Release Notes ### Upgrade guide From 0a4c160fea8c3e616d59ed0c69e2a5b8c8137c1b Mon Sep 17 00:00:00 2001 From: Aayush Sabharwal Date: Wed, 28 May 2025 23:26:21 +0530 Subject: [PATCH 2/6] docs: mention v10 in docs --- docs/src/index.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/src/index.md b/docs/src/index.md index 3f079fa1d8..f742975802 100644 --- a/docs/src/index.md +++ b/docs/src/index.md @@ -36,6 +36,19 @@ If you use ModelingToolkit in your work, please cite the following: ## Feature Summary +!!! danger "ModelingToolkit version 10" + + ModelingToolkit version 10 just released. Please refer to the [changelog](https://github.com/SciML/ModelingToolkit.jl/blob/master/NEWS.md) + for a summary of the changes. Some documentation pages may be broken while downstram + packages update to the new version. + +!!! danger "Temporarily broken discrete systems" + + ModelingToolkit's support for purely explicit systems of discrete update equations + (ones solved via `OrdinaryDiffEqFunctionMap.jl`) is temporarily broken. While such + systems can be created, simplfied and solved there are issues with the naming of + simplified unknowns and symbolic indexing of the problem/solution. + ModelingToolkit.jl is a symbolic-numeric modeling package. Thus it combines some of the features from symbolic computing packages like SymPy or Mathematica with the ideas of equation-based modeling systems like the causal Simulink and the From 294f1847cd05a22a51533d5a7681ebef7d557419 Mon Sep 17 00:00:00 2001 From: Aayush Sabharwal Date: Wed, 28 May 2025 23:26:50 +0530 Subject: [PATCH 3/6] chore: remove `sources` section from Project.toml --- Project.toml | 5 ----- 1 file changed, 5 deletions(-) diff --git a/Project.toml b/Project.toml index e77aa6377c..1f51599a51 100644 --- a/Project.toml +++ b/Project.toml @@ -201,10 +201,5 @@ StochasticDiffEq = "789caeaf-c7a9-5a7d-9973-96adeb23e2a0" Sundials = "c3572dad-4567-51f8-b174-8c6c989267f4" Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40" -[sources] -ModelingToolkitStandardLibrary = { url = "https://github.com/SciML/ModelingToolkitStandardLibrary.jl/", rev = "mtk-v10" } -OptimizationBase = { url = "https://github.com/AayushSabharwal/OptimizationBase.jl", rev = "as/mtk-v10" } -OptimizationMOI = { url = "https://github.com/AayushSabharwal/Optimization.jl", subdir = "lib/OptimizationMOI", rev = "as/mtk-v10" } - [targets] 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"] From f5f6fb91bb2f0f1451a20c9582bf5f584f2d1f15 Mon Sep 17 00:00:00 2001 From: Aayush Sabharwal Date: Wed, 28 May 2025 23:53:21 +0530 Subject: [PATCH 4/6] docs: temporarily remove downstream libs from docs, mark some pages as draft --- docs/Project.toml | 10 ---------- docs/src/examples/remake.md | 4 ++++ docs/src/tutorials/disturbance_modeling.md | 4 ++++ docs/src/tutorials/optimization.md | 4 ++++ 4 files changed, 12 insertions(+), 10 deletions(-) diff --git a/docs/Project.toml b/docs/Project.toml index f9cf903ed7..ef6af51d79 100644 --- a/docs/Project.toml +++ b/docs/Project.toml @@ -4,7 +4,6 @@ BenchmarkTools = "6e4b80f9-dd63-53aa-95a3-0cdb28fa8baf" BifurcationKit = "0f109fa4-8a5d-4b75-95aa-f515264e7665" CairoMakie = "13f3f980-e62b-5c42-98c6-ff1f3baf88f0" ControlSystemsBase = "aaaaaaaa-a6ca-5380-bf3e-84a91bcd477e" -ControlSystemsMTK = "687d7614-c7e5-45fc-bfc3-9ee385575c88" DataInterpolations = "82cc6244-b520-54b8-b5a6-8a565e85f1d0" Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f" Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4" @@ -16,9 +15,6 @@ ModelingToolkit = "961ee093-0014-501f-94e3-6117800e7a78" ModelingToolkitStandardLibrary = "16a59e39-deab-5bd0-87e4-056b12336739" NonlinearSolve = "8913a72c-1f9b-4ce2-8d82-65094dcecaec" Optim = "429524aa-4258-5aef-a3af-852621145aeb" -Optimization = "7f7a1694-90dd-40f0-9382-eb1efda571ba" -OptimizationBase = "bca83a33-5cc9-4baa-983d-23429ab6bcbb" -OptimizationOptimJL = "36348300-93cb-4f02-beb5-3c3902f8871e" OrdinaryDiffEq = "1dea7af3-3e70-54e6-95c3-0bf5283fa5ed" Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80" PreallocationTools = "d236fae5-4411-538c-8e31-a6e3d9e00b46" @@ -30,10 +26,6 @@ SymbolicUtils = "d1185830-fcd6-423d-90d6-eec64667417b" Symbolics = "0c5d862f-8b57-4792-8d23-62f2024744c7" Unitful = "1986cc42-f94f-5a68-af5c-568840ba703d" -[sources] -ModelingToolkitStandardLibrary = {rev = "mtk-v10", url = "https://github.com/SciML/ModelingToolkitStandardLibrary.jl/"} -OptimizationBase = {rev = "as/mtk-v10", url = "https://github.com/AayushSabharwal/OptimizationBase.jl"} - [compat] Attractors = "1.24" BenchmarkTools = "1.3" @@ -49,8 +41,6 @@ ModelingToolkit = "10" ModelingToolkitStandardLibrary = "2.19" NonlinearSolve = "3, 4" Optim = "1.7" -Optimization = "3.9, 4" -OptimizationOptimJL = "0.1, 0.4" OrdinaryDiffEq = "6.31" Plots = "1.36" PreallocationTools = "0.4" diff --git a/docs/src/examples/remake.md b/docs/src/examples/remake.md index 9d40a83dbf..b42315304e 100644 --- a/docs/src/examples/remake.md +++ b/docs/src/examples/remake.md @@ -1,3 +1,7 @@ +```@meta +Draft = true +``` + # Optimizing through an ODE solve and re-creating MTK Problems Solving an ODE as part of an `OptimizationProblem`'s loss function is a common scenario. diff --git a/docs/src/tutorials/disturbance_modeling.md b/docs/src/tutorials/disturbance_modeling.md index 41c7bd86ee..341077b76b 100644 --- a/docs/src/tutorials/disturbance_modeling.md +++ b/docs/src/tutorials/disturbance_modeling.md @@ -1,3 +1,7 @@ +```@meta +Draft = true +``` + # Disturbance and input modeling modeling Disturbances are often seen as external factors that influence a system. Modeling and simulation of such external influences is common in order to ensure that the plant and or control system can adequately handle or suppress these disturbances. Disturbance modeling is also integral to the problem of state estimation, indeed, modeling how disturbances affect the evolution of the state of the system is crucial in order to accurately estimate this state. diff --git a/docs/src/tutorials/optimization.md b/docs/src/tutorials/optimization.md index 9eb72b36ea..d299416412 100644 --- a/docs/src/tutorials/optimization.md +++ b/docs/src/tutorials/optimization.md @@ -1,3 +1,7 @@ +```@meta +Draft = true +``` + # Modeling Optimization Problems ModelingToolkit.jl is not only useful for generating initial value problems (`ODEProblem`). From 58b37665b10f56c94ef71cc323638ca95ecd4288 Mon Sep 17 00:00:00 2001 From: Aayush Sabharwal Date: Wed, 28 May 2025 23:56:08 +0530 Subject: [PATCH 5/6] refactor: remove old `find/replace` in `expand_connections` --- src/systems/connectors.jl | 48 ++++++++++++++++----------------------- 1 file changed, 19 insertions(+), 29 deletions(-) diff --git a/src/systems/connectors.jl b/src/systems/connectors.jl index d771445074..cf2f24a7d1 100644 --- a/src/systems/connectors.jl +++ b/src/systems/connectors.jl @@ -519,11 +519,11 @@ function connection2set!(connectionsets, namespace, ss, isouter; end function generate_connection_set( - sys::AbstractSystem, find = nothing, replace = nothing; scalarize = false) + sys::AbstractSystem; scalarize = false) connectionsets = ConnectionSet[] domain_csets = ConnectionSet[] sys = generate_connection_set!( - connectionsets, domain_csets, sys, find, replace, scalarize, nothing, ignored_connections(sys)) + connectionsets, domain_csets, sys, scalarize, nothing, ignored_connections(sys)) csets = merge(connectionsets) domain_csets = merge([csets; domain_csets], true) @@ -627,7 +627,7 @@ Generate connection sets from `connect` equations. for no namespace (if `sys` is top-level). """ function generate_connection_set!(connectionsets, domain_csets, - sys::AbstractSystem, find, replace, scalarize, namespace = nothing, + sys::AbstractSystem, scalarize, namespace = nothing, ignored_connects = (HierarchyAnalysisPointT[], HierarchyAnalysisPointT[])) subsys = get_systems(sys) ignored_system_aps, ignored_variable_aps = ignored_connects @@ -646,31 +646,21 @@ function generate_connection_set!(connectionsets, domain_csets, # causal variable connections will be expanded before we get here, # but this guard is useful for `n_expanded_connection_equations`. is_causal_variable_connection(rhs) && continue - if find !== nothing && find(rhs, _getname(namespace)) - neweq, extra_unknown = replace(rhs, _getname(namespace)) - if extra_unknown isa AbstractArray - append!(extra_unknowns, unwrap.(extra_unknown)) - elseif extra_unknown !== nothing - push!(extra_unknowns, extra_unknown) - end - neweq isa AbstractArray ? append!(eqs, neweq) : push!(eqs, neweq) + if lhs isa Connection && get_systems(lhs) === :domain + connected_systems = get_systems(rhs) + connection2set!(domain_csets, namespace, connected_systems, isouter; + ignored_systems = systems_to_ignore( + ignored_system_aps, connected_systems), + ignored_variables = variables_to_ignore( + ignored_variable_aps, connected_systems)) + elseif isconnection(rhs) + push!(cts, get_systems(rhs)) else - if lhs isa Connection && get_systems(lhs) === :domain - connected_systems = get_systems(rhs) - connection2set!(domain_csets, namespace, connected_systems, isouter; - ignored_systems = systems_to_ignore( - ignored_system_aps, connected_systems), - ignored_variables = variables_to_ignore( - ignored_variable_aps, connected_systems)) - elseif isconnection(rhs) - push!(cts, get_systems(rhs)) + # split connections and equations + if eq.lhs isa AbstractArray || eq.rhs isa AbstractArray + append!(eqs, Symbolics.scalarize(eq)) else - # split connections and equations - if eq.lhs isa AbstractArray || eq.rhs isa AbstractArray - append!(eqs, Symbolics.scalarize(eq)) - else - push!(eqs, eq) - end + push!(eqs, eq) end end end @@ -699,7 +689,7 @@ function generate_connection_set!(connectionsets, domain_csets, end @set! sys.systems = map( s -> generate_connection_set!(connectionsets, domain_csets, s, - find, replace, scalarize, renamespace(namespace, s), + scalarize, renamespace(namespace, s), ignored_systems_for_subsystem.((s,), ignored_connects)), subsys) @set! sys.eqs = eqs @@ -870,11 +860,11 @@ function expand_variable_connections(sys::AbstractSystem; ignored_variables = no return sys end -function expand_connections(sys::AbstractSystem, find = nothing, replace = nothing; +function expand_connections(sys::AbstractSystem; debug = false, tol = 1e-10, scalarize = true) sys = remove_analysis_points(sys) sys = expand_variable_connections(sys) - sys, (csets, domain_csets) = generate_connection_set(sys, find, replace; scalarize) + sys, (csets, domain_csets) = generate_connection_set(sys; scalarize) ceqs, instream_csets = generate_connection_equations_and_stream_connections(csets) _sys = expand_instream(instream_csets, sys; debug = debug, tol = tol) sys = flatten(sys, true) From 716c8aa5bfda3ac369404dbadd3fc98bd88e8064 Mon Sep 17 00:00:00 2001 From: Aayush Sabharwal Date: Thu, 29 May 2025 13:42:35 +0530 Subject: [PATCH 6/6] docs: rename `ODESystem` to `System` --- docs/src/API/variables.md | 4 +-- docs/src/basics/AbstractSystem.md | 2 +- docs/src/basics/Composition.md | 26 ++++++++--------- docs/src/basics/Debugging.md | 4 +-- docs/src/basics/Events.md | 28 +++++++++---------- docs/src/basics/FAQ.md | 8 +++--- docs/src/basics/InputOutput.md | 2 +- docs/src/basics/Linearization.md | 6 ++-- docs/src/basics/MTKLanguage.md | 20 ++----------- docs/src/basics/Precompilation.md | 2 +- docs/src/basics/Validation.md | 2 +- docs/src/examples/higher_order.md | 2 +- docs/src/examples/perturbation.md | 6 ++-- docs/src/examples/tearing_parallelism.md | 2 +- docs/src/index.md | 6 ++-- docs/src/internals.md | 4 +-- docs/src/tutorials/acausal_components.md | 6 ++-- docs/src/tutorials/attractors.md | 2 +- .../bifurcation_diagram_computation.md | 6 ++-- docs/src/tutorials/fmi.md | 2 +- docs/src/tutorials/initialization.md | 2 +- docs/src/tutorials/modelingtoolkitize.md | 2 +- docs/src/tutorials/nonlinear.md | 2 +- docs/src/tutorials/ode_modeling.md | 6 ++-- docs/src/tutorials/optimization.md | 2 +- .../tutorials/programmatically_generating.md | 16 +++++------ docs/src/tutorials/stochastic_diffeq.md | 4 +-- 27 files changed, 80 insertions(+), 94 deletions(-) diff --git a/docs/src/API/variables.md b/docs/src/API/variables.md index 0ff2e7799d..04d85e06b9 100644 --- a/docs/src/API/variables.md +++ b/docs/src/API/variables.md @@ -34,7 +34,7 @@ When variables with descriptions are present in systems, they will be printed wh ```@example metadata @variables u(t) [description = "A short description of u"] @parameters p [description = "A description of p"] -@named sys = ODESystem([u ~ p], t) +@named sys = System([u ~ p], t) show(stdout, "text/plain", sys) # hide ``` @@ -298,7 +298,7 @@ In the example below, we define a system with tunable parameters and extract bou @parameters k [tunable = true, bounds = (0, Inf)] eqs = [D(x) ~ (-x + k * u) / T # A first-order system with time constant T and gain k y ~ x] -sys = ODESystem(eqs, t, name = :tunable_first_order) +sys = System(eqs, t, name = :tunable_first_order) ``` ```@example metadata diff --git a/docs/src/basics/AbstractSystem.md b/docs/src/basics/AbstractSystem.md index 62f842b2b2..61b6ef4fff 100644 --- a/docs/src/basics/AbstractSystem.md +++ b/docs/src/basics/AbstractSystem.md @@ -12,7 +12,7 @@ model manipulation and compilation. There are three immediate subtypes of `AbstractSystem`, classified by how many independent variables each type has: - `AbstractTimeIndependentSystem`: has no independent variable (e.g.: `NonlinearSystem`) - - `AbstractTimeDependentSystem`: has a single independent variable (e.g.: `ODESystem`) + - `AbstractTimeDependentSystem`: has a single independent variable (e.g.: `System`) - `AbstractMultivariateSystem`: may have multiple independent variables (e.g.: `PDESystem`) ## Constructors and Naming diff --git a/docs/src/basics/Composition.md b/docs/src/basics/Composition.md index f6abe97d38..01a755e15c 100644 --- a/docs/src/basics/Composition.md +++ b/docs/src/basics/Composition.md @@ -21,7 +21,7 @@ using ModelingToolkit: t_nounits as t, D_nounits as D function decay(; name) @parameters a @variables x(t) f(t) - ODESystem([ + System([ D(x) ~ -a * x + f ], t; name = name) @@ -31,7 +31,7 @@ end @named decay2 = decay() connected = compose( - ODESystem([decay2.f ~ decay1.x + System([decay2.f ~ decay1.x D(decay1.f) ~ 0], t; name = :connected), decay1, decay2) equations(connected) @@ -69,7 +69,7 @@ subsystems. A model is the composition of itself and its subsystems. For example, if we have: ```julia -@named sys = compose(ODESystem(eqs, indepvar, unknowns, ps), subsys) +@named sys = compose(System(eqs, indepvar, unknowns, ps), subsys) ``` 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 ```julia # ... -sys = ODESystem( +sys = System( # ... # directly in the defaults argument defaults = Pair{Num, Any}[x => u, @@ -144,20 +144,20 @@ d = GlobalScope(d) p = [a, b, c, d] -level0 = ODESystem(Equation[], t, [], p; name = :level0) -level1 = ODESystem(Equation[], t, [], []; name = :level1) ∘ level0 +level0 = System(Equation[], t, [], p; name = :level0) +level1 = System(Equation[], t, [], []; name = :level1) ∘ level0 parameters(level1) #level0₊a #b #c #d -level2 = ODESystem(Equation[], t, [], []; name = :level2) ∘ level1 +level2 = System(Equation[], t, [], []; name = :level2) ∘ level1 parameters(level2) #level1₊level0₊a #level1₊b #c #d -level3 = ODESystem(Equation[], t, [], []; name = :level3) ∘ level2 +level3 = System(Equation[], t, [], []; name = :level3) ∘ level2 parameters(level3) #level2₊level1₊level0₊a #level2₊level1₊b @@ -194,12 +194,12 @@ using ModelingToolkit: t_nounits as t, D_nounits as D N = S + I + R @parameters β, γ -@named seqn = ODESystem([D(S) ~ -β * S * I / N], t) -@named ieqn = ODESystem([D(I) ~ β * S * I / N - γ * I], t) -@named reqn = ODESystem([D(R) ~ γ * I], t) +@named seqn = System([D(S) ~ -β * S * I / N], t) +@named ieqn = System([D(I) ~ β * S * I / N - γ * I], t) +@named reqn = System([D(R) ~ γ * I], t) sir = compose( - ODESystem( + System( [ S ~ ieqn.S, I ~ seqn.I, @@ -266,6 +266,6 @@ equations are discontinuous in either the unknown or one of its derivatives. Thi causes the solver to take very small steps around the discontinuity, and sometimes leads to early stopping due to `dt <= dt_min`. The correct way to handle such dynamics is to tell the solver about the discontinuity by a -root-finding equation, which can be modeling using [`ODESystem`](@ref)'s event +root-finding equation, which can be modeling using [`System`](@ref)'s event support. Please see the tutorial on [Callbacks and Events](@ref events) for details and examples. diff --git a/docs/src/basics/Debugging.md b/docs/src/basics/Debugging.md index 5bc509acfd..4f9c2c07d7 100644 --- a/docs/src/basics/Debugging.md +++ b/docs/src/basics/Debugging.md @@ -12,7 +12,7 @@ using ModelingToolkit: t_nounits as t, D_nounits as D @variables u1(t) u2(t) u3(t) eqs = [D(u1) ~ -√(u1), D(u2) ~ -√(u2), D(u3) ~ -√(u3)] defaults = [u1 => 1.0, u2 => 2.0, u3 => 3.0] -@named sys = ODESystem(eqs, t; defaults) +@named sys = System(eqs, t; defaults) sys = mtkcompile(sys) ``` @@ -38,7 +38,7 @@ We could have figured that out ourselves, but it is not always so obvious for mo Suppose we also want to validate that `u1 + u2 >= 2.0`. We can do this via the assertions functionality. ```@example debug -@mtkcompile sys = ODESystem(eqs, t; defaults, assertions = [(u1 + u2 >= 2.0) => "Oh no!"]) +@mtkcompile sys = System(eqs, t; defaults, assertions = [(u1 + u2 >= 2.0) => "Oh no!"]) ``` The assertions must be an iterable of pairs, where the first element is the symbolic condition and diff --git a/docs/src/basics/Events.md b/docs/src/basics/Events.md index 5d5df0a377..89f874b08b 100644 --- a/docs/src/basics/Events.md +++ b/docs/src/basics/Events.md @@ -9,7 +9,7 @@ or into more specialized callback types from the [DiffEqCallbacks.jl](https://docs.sciml.ai/DiffEqDocs/stable/features/callback_library/) library. -[`ODESystem`](@ref)s and [`SDESystem`](@ref)s accept keyword arguments +[`System`](@ref)s and [`SDESystem`](@ref)s accept keyword arguments `continuous_events` and `discrete_events` to symbolically encode continuous or discrete callbacks. [`JumpSystem`](@ref)s currently support only `discrete_events`. Continuous events are applied when a given condition becomes @@ -59,7 +59,7 @@ For example, consider the following system. ```julia @variables x(t) y(t) @parameters p(t) -@mtkcompile sys = ODESystem([x * y ~ p, D(x) ~ 0], t) +@mtkcompile sys = System([x * y ~ p, D(x) ~ 0], t) event = [t == 1] => [x ~ Pre(x) + 1] ``` @@ -132,7 +132,7 @@ function UnitMassWithFriction(k; name) @variables x(t)=0 v(t)=0 eqs = [D(x) ~ v D(v) ~ sin(t) - k * sign(v)] - ODESystem(eqs, t; continuous_events = [v ~ 0], name) # when v = 0 there is a discontinuity + System(eqs, t; continuous_events = [v ~ 0], name) # when v = 0 there is a discontinuity end @mtkcompile m = UnitMassWithFriction(0.7) prob = ODEProblem(m, Pair[], (0, 10pi)) @@ -154,7 +154,7 @@ like this root_eqs = [x ~ 0] # the event happens at the ground x(t) = 0 affect = [v ~ -Pre(v)] # the effect is that the velocity changes sign -@mtkcompile ball = ODESystem( +@mtkcompile ball = System( [D(x) ~ v D(v) ~ -9.8], t; continuous_events = root_eqs => affect) # equation => affect @@ -175,7 +175,7 @@ Multiple events? No problem! This example models a bouncing ball in 2D that is e continuous_events = [[x ~ 0] => [vx ~ -Pre(vx)] [y ~ -1.5, y ~ 1.5] => [vy ~ -Pre(vy)]] -@mtkcompile ball = ODESystem( +@mtkcompile ball = System( [ D(x) ~ vx, D(y) ~ vy, @@ -255,7 +255,7 @@ end reflect = [x ~ 0] => (bb_affect!, [v], [], [], nothing) -@mtkcompile bb_sys = ODESystem(bb_eqs, t, sts, par, +@mtkcompile bb_sys = System(bb_eqs, t, sts, par, continuous_events = reflect) u0 = [v => 0.0, x => 1.0] @@ -300,7 +300,7 @@ injection = (t == tinject) => [N ~ Pre(N) + M] u0 = [N => 0.0] tspan = (0.0, 20.0) p = [α => 100.0, tinject => 10.0, M => 50] -@mtkcompile osys = ODESystem(eqs, t, [N], [α, M, tinject]; discrete_events = injection) +@mtkcompile osys = System(eqs, t, [N], [α, M, tinject]; discrete_events = injection) oprob = ODEProblem(osys, u0, tspan, p) sol = solve(oprob, Tsit5(); tstops = 10.0) plot(sol) @@ -319,7 +319,7 @@ to ```@example events injection = ((t == tinject) & (N < 50)) => [N ~ Pre(N) + M] -@mtkcompile osys = ODESystem(eqs, t, [N], [M, tinject, α]; discrete_events = injection) +@mtkcompile osys = System(eqs, t, [N], [M, tinject, α]; discrete_events = injection) oprob = ODEProblem(osys, u0, tspan, p) sol = solve(oprob, Tsit5(); tstops = 10.0) plot(sol) @@ -346,7 +346,7 @@ killing = ModelingToolkit.SymbolicDiscreteCallback( tspan = (0.0, 30.0) p = [α => 100.0, tinject => 10.0, M => 50, tkill => 20.0] -@mtkcompile osys = ODESystem(eqs, t, [N], [α, M, tinject, tkill]; +@mtkcompile osys = System(eqs, t, [N], [α, M, tinject, tkill]; discrete_events = [injection, killing]) oprob = ODEProblem(osys, u0, tspan, p) sol = solve(oprob, Tsit5(); tstops = [10.0, 20.0]) @@ -375,7 +375,7 @@ killing = ModelingToolkit.SymbolicDiscreteCallback( [20.0] => [α ~ 0.0], discrete_parameters = α, iv = t) p = [α => 100.0, M => 50] -@mtkcompile osys = ODESystem(eqs, t, [N], [α, M]; +@mtkcompile osys = System(eqs, t, [N], [α, M]; discrete_events = [injection, killing]) oprob = ODEProblem(osys, u0, tspan, p) sol = solve(oprob, Tsit5()) @@ -415,7 +415,7 @@ example: ev = ModelingToolkit.SymbolicDiscreteCallback( 1.0 => [c ~ Pre(c) + 1], discrete_parameters = c, iv = t) -@mtkcompile sys = ODESystem( +@mtkcompile sys = System( D(x) ~ c * cos(x), t, [x], [c]; discrete_events = [ev]) prob = ODEProblem(sys, [x => 0.0], (0.0, 2pi), [c => 1.0]) @@ -436,7 +436,7 @@ will be saved. If we repeat the above example with `c` not a `discrete_parameter @variables x(t) @parameters c(t) -@mtkcompile sys = ODESystem( +@mtkcompile sys = System( D(x) ~ c * cos(x), t, [x], [c]; discrete_events = [1.0 => [c ~ Pre(c) + 1]]) prob = ODEProblem(sys, [x => 0.0], (0.0, 2pi), [c => 1.0]) @@ -537,7 +537,7 @@ will write `furnace_on = false` back to the system, and when `temp = furnace_on_ to the system. ```@example events -@named sys = ODESystem( +@named sys = System( eqs, t, [temp], params; continuous_events = [furnace_disable, furnace_enable]) ss = mtkcompile(sys) prob = ODEProblem(ss, [temp => 0.0, furnace_on => true], (0.0, 10.0)) @@ -650,7 +650,7 @@ affect activation point, with -1 mapped to 0. We can now simulate the encoder. ```@example events -@named sys = ODESystem( +@named sys = System( eqs, t, [theta, omega], params; continuous_events = [qAevt, qBevt]) ss = mtkcompile(sys) prob = ODEProblem(ss, [theta => 0.0], (0.0, pi)) diff --git a/docs/src/basics/FAQ.md b/docs/src/basics/FAQ.md index e83b1f1336..e3b12b46ab 100644 --- a/docs/src/basics/FAQ.md +++ b/docs/src/basics/FAQ.md @@ -205,7 +205,7 @@ eqs = [x1 + x2 + 1 ~ 0 x1 + x2 + x3 + 2 ~ 0 x1 + D(x3) + x4 + 3 ~ 0 2 * D(D(x1)) + D(D(x2)) + D(D(x3)) + D(x4) + 4 ~ 0] -@named sys = ODESystem(eqs, t) +@named sys = System(eqs, t) sys = mtkcompile(sys) prob = ODEProblem(sys, [], (0, 1)) ``` @@ -237,7 +237,7 @@ using ModelingToolkit: t_nounits as t, D_nounits as D sts = @variables x1(t) = 0.0 eqs = [D(x1) ~ 1.1 * x1] -@mtkcompile sys = ODESystem(eqs, t) +@mtkcompile sys = System(eqs, t) prob = ODEProblem{false}(sys, [], (0, 1); u0_constructor = x -> SVector(x...)) ``` @@ -252,7 +252,7 @@ using ModelingToolkit @independent_variables x D = Differential(x) @variables y(x) -@named sys = ODESystem([D(y) ~ x], x) +@named sys = System([D(y) ~ x], x) ``` ## Ordering of tunable parameters @@ -279,7 +279,7 @@ using ModelingToolkit @parameters p q[1:3] r[1:2, 1:2] -@named sys = ODESystem(Equation[], ModelingToolkit.t_nounits, [], [p, q, r]) +@named sys = System(Equation[], ModelingToolkit.t_nounits, [], [p, q, r]) sys = complete(sys) ``` diff --git a/docs/src/basics/InputOutput.md b/docs/src/basics/InputOutput.md index 35a3885dbd..2e9da1c2db 100644 --- a/docs/src/basics/InputOutput.md +++ b/docs/src/basics/InputOutput.md @@ -44,7 +44,7 @@ import ModelingToolkit: t_nounits as t, D_nounits as D eqs = [D(x) ~ -k * (x + u) y ~ x] -@named sys = ODESystem(eqs, t) +@named sys = System(eqs, t) f, x_sym, ps = ModelingToolkit.generate_control_function(sys, [u], simplify = true); nothing # hide ``` diff --git a/docs/src/basics/Linearization.md b/docs/src/basics/Linearization.md index 27b8ec9903..3951aab28a 100644 --- a/docs/src/basics/Linearization.md +++ b/docs/src/basics/Linearization.md @@ -29,12 +29,12 @@ eqs = [u ~ kp * (r - y) # P controller D(x) ~ -x + u # First-order plant y ~ x] # Output equation -@named sys = ODESystem(eqs, t) # Do not call @mtkcompile when linearizing +@named sys = System(eqs, t) # Do not call @mtkcompile when linearizing matrices, simplified_sys = linearize(sys, [r], [y]) # Linearize from r to y matrices ``` -The named tuple `matrices` contains the matrices of the linear statespace representation, while `simplified_sys` is an `ODESystem` that, among other things, indicates the unknown variable order in the linear system through +The named tuple `matrices` contains the matrices of the linear statespace representation, while `simplified_sys` is an `System` that, among other things, indicates the unknown variable order in the linear system through ```@example LINEARIZE using ModelingToolkit: inputs, outputs @@ -78,7 +78,7 @@ eqs = [D(x) ~ v D(v) ~ -k * x - k3 * x^3 - c * v + 10u.u y.u ~ x] -@named duffing = ODESystem(eqs, t, systems = [y, u], defaults = [u.u => 0]) +@named duffing = System(eqs, t, systems = [y, u], defaults = [u.u => 0]) # pass a constant value for `x`, since it is the variable we will change in operating points linfun, simplified_sys = linearization_function(duffing, [u.u], [y.u]; op = Dict(x => NaN)); diff --git a/docs/src/basics/MTKLanguage.md b/docs/src/basics/MTKLanguage.md index 05847581f6..09fa6d2daa 100644 --- a/docs/src/basics/MTKLanguage.md +++ b/docs/src/basics/MTKLanguage.md @@ -16,7 +16,7 @@ equations. ### [Defining components with `@mtkmodel`](@id mtkmodel) `@mtkmodel` is a convenience macro to define components. It returns -`ModelingToolkit.Model`, which includes a system constructor (`ODESystem` by +`ModelingToolkit.Model`, which includes a system constructor (`System` by default), a `structure` dictionary with metadata, and flag `isconnector` which is set to `false`. @@ -263,7 +263,7 @@ end ### Setting the type of system: -By default `@mtkmodel` returns an ODESystem. Different types of system can be +By default `@mtkmodel` returns an System. Different types of system can be defined with the following syntax: ``` @@ -273,20 +273,6 @@ end ``` -Example: - -```@example mtkmodel-example -@mtkmodel Float2Bool::DiscreteSystem begin - @variables begin - u(t)::Float64 - y(t)::Bool - end - @equations begin - y ~ u != 0 - end -end -``` - ## Connectors Connectors are special models that can be used to connect different components together. @@ -301,7 +287,7 @@ MTK provides 3 distinct connectors: ### [Defining connectors with `@connector`](@id connector) `@connector` returns `ModelingToolkit.Model`. It includes a constructor that returns -a connector system (`ODESystem` by default), a `structure` dictionary with metadata, and flag `isconnector` +a connector system (`System` by default), a `structure` dictionary with metadata, and flag `isconnector` which is set to `true`. A simple connector can be defined with syntax similar to following example: diff --git a/docs/src/basics/Precompilation.md b/docs/src/basics/Precompilation.md index 0bf9a86653..3bac7fcc31 100644 --- a/docs/src/basics/Precompilation.md +++ b/docs/src/basics/Precompilation.md @@ -21,7 +21,7 @@ module PrecompilationMWE using ModelingToolkit @variables x(ModelingToolkit.t_nounits) -@named sys = ODESystem([ModelingToolkit.D_nounits(x) ~ -x + 1], ModelingToolkit.t_nounits) +@named sys = System([ModelingToolkit.D_nounits(x) ~ -x + 1], ModelingToolkit.t_nounits) prob = ODEProblem(mtkcompile(sys), [x => 30.0], (0, 100), [], eval_expression = true, eval_module = @__MODULE__) diff --git a/docs/src/basics/Validation.md b/docs/src/basics/Validation.md index 74715d351e..6e17beeded 100644 --- a/docs/src/basics/Validation.md +++ b/docs/src/basics/Validation.md @@ -110,7 +110,7 @@ end sts = @variables a(t)=0 [unit = u"cm"] ps = @parameters s=-1 [unit = u"cm"] c=c [unit = u"cm"] eqs = [D(a) ~ dummycomplex(c, s);] -sys = ODESystem( +sys = System( eqs, t, [sts...;], [ps...;], name = :sys, checks = ~ModelingToolkit.CheckUnits) sys_simple = mtkcompile(sys) ``` diff --git a/docs/src/examples/higher_order.md b/docs/src/examples/higher_order.md index 95480e283b..e8dda823e0 100644 --- a/docs/src/examples/higher_order.md +++ b/docs/src/examples/higher_order.md @@ -42,7 +42,7 @@ Note that we could've used an alternative syntax for 2nd order, i.e. and this syntax extends to `N`-th order. Also, we can use `*` or `∘` to compose `Differential`s, like `Differential(t) * Differential(x)`. -Now let's transform this into the `ODESystem` of first order components. +Now let's transform this into the `System` of first order components. We do this by calling `mtkcompile`: Now we can directly numerically solve the lowered system. Note that, diff --git a/docs/src/examples/perturbation.md b/docs/src/examples/perturbation.md index 20cef4067c..5dfe84c600 100644 --- a/docs/src/examples/perturbation.md +++ b/docs/src/examples/perturbation.md @@ -40,13 +40,13 @@ eqs_pert = taylor_coeff(eq_pert, ϵ, 0:2) The 0-th order equation can be solved analytically, but ModelingToolkit does currently not feature automatic analytical solution of ODEs, so we proceed with solving it numerically. -These are the ODEs we want to solve. Now construct an `ODESystem`, which automatically inserts dummy derivatives for the velocities: +These are the ODEs we want to solve. Now construct an `System`, which automatically inserts dummy derivatives for the velocities: ```@example perturbation @mtkcompile sys = System(eqs_pert, t) ``` -To solve the `ODESystem`, we generate an `ODEProblem` with initial conditions $x(0) = 0$, and $ẋ(0) = 1$, and solve it: +To solve the `System`, we generate an `ODEProblem` with initial conditions $x(0) = 0$, and $ẋ(0) = 1$, and solve it: ```@example perturbation using OrdinaryDiffEq @@ -82,7 +82,7 @@ eq = D(D(x)) + 2 * ϵ * D(x) + x ~ 0 with initial conditions $x(0) = 0$ and $ẋ(0) = 1$. With $ϵ = 0$, the problem reduces to the simple linear harmonic oscillator with the exact solution $x(t) = \sin(t)$. -We follow the same steps as in the previous example to construct the `ODESystem`: +We follow the same steps as in the previous example to construct the `System`: ```@example perturbation eq_pert = substitute(eq, x => x_series) diff --git a/docs/src/examples/tearing_parallelism.md b/docs/src/examples/tearing_parallelism.md index 4ecc8d2a45..f123f8b7b3 100644 --- a/docs/src/examples/tearing_parallelism.md +++ b/docs/src/examples/tearing_parallelism.md @@ -1,4 +1,4 @@ -# Exposing More Parallelism By Tearing Algebraic Equations in ODESystems +# Exposing More Parallelism By Tearing Algebraic Equations in Systems Sometimes it can be very non-trivial to parallelize a system. In this tutorial, we will demonstrate how to make use of `mtkcompile` to expose more diff --git a/docs/src/index.md b/docs/src/index.md index f742975802..6050af538e 100644 --- a/docs/src/index.md +++ b/docs/src/index.md @@ -135,7 +135,7 @@ Below is an incomplete list of extension libraries one may want to be aware of: - [MomentClosure.jl](https://augustinas1.github.io/MomentClosure.jl/dev/): Automatic transformation of ReactionSystems into deterministic systems - + Generates ODESystems for the moment closures + + Generates Systems for the moment closures + Allows for geometrically-distributed random reaction rates - [ReactionMechanismSimulator.jl](https://github.com/ReactionMechanismGenerator/ReactionMechanismSimulator.jl): Simulating and analyzing large chemical reaction mechanisms @@ -159,14 +159,14 @@ Below is an incomplete list of extension libraries one may want to be aware of: All of the symbolic systems have a direct conversion to a numerical system, which can then be handled through the SciML interfaces. For example, after building a -model and performing symbolic manipulations, an `ODESystem` can be converted into +model and performing symbolic manipulations, an `System` can be converted into an `ODEProblem` to then be solved by a numerical ODE solver. Below is a list of the solver libraries which are the numerical targets of the ModelingToolkit system: - [DifferentialEquations.jl](https://docs.sciml.ai/DiffEqDocs/stable/) - + Multi-package interface of high performance numerical solvers for `ODESystem`, + + Multi-package interface of high performance numerical solvers for `System`, `SDESystem`, and `JumpSystem` - [NonlinearSolve.jl](https://docs.sciml.ai/NonlinearSolve/stable/) diff --git a/docs/src/internals.md b/docs/src/internals.md index ed83192f21..0381e854b0 100644 --- a/docs/src/internals.md +++ b/docs/src/internals.md @@ -22,13 +22,13 @@ The procedure for variable elimination inside [`mtkcompile`](@ref) is 1. [`ModelingToolkit.initialize_system_structure`](@ref). 2. [`ModelingToolkit.alias_elimination`](@ref). This step moves equations into `observed(sys)`. - 3. [`ModelingToolkit.dae_index_lowering`](@ref) by means of [`pantelides!`](@ref) (if the system is an [`ODESystem`](@ref)). + 3. [`ModelingToolkit.dae_index_lowering`](@ref) by means of [`pantelides!`](@ref) (if the system is an [`System`](@ref)). 4. [`ModelingToolkit.tearing`](@ref). ## Preparing a system for simulation Before a simulation or optimization can be performed, the symbolic equations stored in an [`AbstractSystem`](@ref) must be converted into executable code. This step typically occurs after the simplification explained above, and is performed when an instance of a [`SciMLBase.AbstractSciMLProblem`](@ref), such as a [`ODEProblem`](@ref), is constructed. -The call chain typically looks like this, with the function names in the case of an `ODESystem` indicated in parentheses +The call chain typically looks like this, with the function names in the case of an `System` indicated in parentheses 1. Problem constructor ([`ODEProblem`](@ref)) 2. Build an `DEFunction` ([`process_DEProblem`](@ref) -> [`ODEFunction`](@ref) diff --git a/docs/src/tutorials/acausal_components.md b/docs/src/tutorials/acausal_components.md index b364be4012..46da36caa4 100644 --- a/docs/src/tutorials/acausal_components.md +++ b/docs/src/tutorials/acausal_components.md @@ -116,7 +116,7 @@ We wish to build the following RC circuit by building individual components and ### Building the Component Library -For each of our components, we use ModelingToolkit `Model` that emits an `ODESystem`. +For each of our components, we use ModelingToolkit `Model` that emits an `System`. At the top, we start with defining the fundamental qualities of an electric circuit component. At every input and output pin, a circuit component has two values: the current at the pin and the voltage. Thus we define the `Pin` @@ -133,7 +133,7 @@ default, variables are equal in a connection. end ``` -Note that this is an incompletely specified ODESystem: it cannot be simulated +Note that this is an incompletely specified System: it cannot be simulated on its own because the equations for `v(t)` and `i(t)` are unknown. Instead, this just gives a common syntax for receiving this pair with some default values. @@ -145,7 +145,7 @@ One can then construct a `Pin` using the `@named` helper macro: Next, we build our ground node. A ground node is just a pin that is connected to a constant voltage reservoir, typically taken to be `V = 0`. Thus to define -this component, we generate an `ODESystem` with a `Pin` subcomponent and specify +this component, we generate an `System` with a `Pin` subcomponent and specify that the voltage in such a `Pin` is equal to zero. This gives: ```@example acausal diff --git a/docs/src/tutorials/attractors.md b/docs/src/tutorials/attractors.md index 426551b017..8b5fecbef9 100644 --- a/docs/src/tutorials/attractors.md +++ b/docs/src/tutorials/attractors.md @@ -38,7 +38,7 @@ eqs = [ ] ``` -Because our dynamical system is super simple, we will directly make an `ODESystem` and cast it in an `ODEProblem` as in the [`ODESystems` tutorial](@ref programmatically). Since all state variables and parameters have a default value we can immediately write +Because our dynamical system is super simple, we will directly make an `System` and cast it in an `ODEProblem` as in the [`Systems` tutorial](@ref programmatically). Since all state variables and parameters have a default value we can immediately write ```@example Attractors @named modlorenz = System(eqs, t) diff --git a/docs/src/tutorials/bifurcation_diagram_computation.md b/docs/src/tutorials/bifurcation_diagram_computation.md index 811ea89e83..3ceb5474ab 100644 --- a/docs/src/tutorials/bifurcation_diagram_computation.md +++ b/docs/src/tutorials/bifurcation_diagram_computation.md @@ -1,6 +1,6 @@ # [Bifurcation Diagrams](@id bifurcation_diagrams) -Bifurcation diagrams describes how, for a dynamic system, the quantity and quality of its steady states changes with a parameter's value. These can be computed through the [BifurcationKit.jl](https://github.com/bifurcationkit/BifurcationKit.jl) package. ModelingToolkit provides a simple interface for creating BifurcationKit compatible `BifurcationProblem`s from `NonlinearSystem`s and `ODESystem`s. All the features provided by BifurcationKit can then be applied to these systems. This tutorial provides a brief introduction for these features, with BifurcationKit.jl providing [a more extensive documentation](https://bifurcationkit.github.io/BifurcationKitDocs.jl/stable/). +Bifurcation diagrams describes how, for a dynamic system, the quantity and quality of its steady states changes with a parameter's value. These can be computed through the [BifurcationKit.jl](https://github.com/bifurcationkit/BifurcationKit.jl) package. ModelingToolkit provides a simple interface for creating BifurcationKit compatible `BifurcationProblem`s from `NonlinearSystem`s and `System`s. All the features provided by BifurcationKit can then be applied to these systems. This tutorial provides a brief introduction for these features, with BifurcationKit.jl providing [a more extensive documentation](https://bifurcationkit.github.io/BifurcationKitDocs.jl/stable/). ### Creating a `BifurcationProblem` @@ -83,9 +83,9 @@ plot(bf; Here, the system exhibits a pitchfork bifurcation at *μ=0.0*. -### Using `ODESystem` inputs +### Using `System` inputs -It is also possible to use `ODESystem`s (rather than `NonlinearSystem`s) as input to `BifurcationProblem`. Here follows a brief such example. +It is also possible to use `System`s (rather than `NonlinearSystem`s) as input to `BifurcationProblem`. Here follows a brief such example. ```@example Bif2 using BifurcationKit, ModelingToolkit, Plots diff --git a/docs/src/tutorials/fmi.md b/docs/src/tutorials/fmi.md index d17452f612..7e949839ef 100644 --- a/docs/src/tutorials/fmi.md +++ b/docs/src/tutorials/fmi.md @@ -106,7 +106,7 @@ constant until the next time the callback triggers. The periodic interval must b more computationally expensive. This model alone does not have any differential variables, and calling `mtkcompile` will lead -to an `ODESystem` with no unknowns. +to an `System` with no unknowns. ```@example fmi mtkcompile(inner) diff --git a/docs/src/tutorials/initialization.md b/docs/src/tutorials/initialization.md index fedb8b9a22..90d86f1521 100644 --- a/docs/src/tutorials/initialization.md +++ b/docs/src/tutorials/initialization.md @@ -4,7 +4,7 @@ While for simple numerical ODEs choosing an initial condition can be an easy affair, with ModelingToolkit's more general differential-algebraic equation (DAE) system there is more care needed due to the flexibility of the solver state. In this tutorial we will walk through the functionality involved in -initialization of ODESystem and the diagnostics to better understand and +initialization of System and the diagnostics to better understand and debug the initialization problem. ## Primer on Initialization of Differential-Algebraic Equations diff --git a/docs/src/tutorials/modelingtoolkitize.md b/docs/src/tutorials/modelingtoolkitize.md index fc74578ea4..8cd8015630 100644 --- a/docs/src/tutorials/modelingtoolkitize.md +++ b/docs/src/tutorials/modelingtoolkitize.md @@ -49,7 +49,7 @@ prob = ODEProblem(rober, [1.0, 0.0, 0.0], (0.0, 1e5), (0.04, 3e7, 1e4)) ``` If we want to get a symbolic representation, we can simply call `modelingtoolkitize` -on the `prob`, which will return an `ODESystem`: +on the `prob`, which will return an `System`: ```@example mtkize @mtkcompile sys = modelingtoolkitize(prob) diff --git a/docs/src/tutorials/nonlinear.md b/docs/src/tutorials/nonlinear.md index 13caf96231..8342eb788b 100644 --- a/docs/src/tutorials/nonlinear.md +++ b/docs/src/tutorials/nonlinear.md @@ -12,7 +12,7 @@ This steady state is reached when the nonlinear system of differential equations is not yet compatible with `NonlinearSystem`. We thus have to use a lower level interface to define nonlinear systems. For an introduction to this interface, read the - [programmatically generating ODESystems tutorial](@ref programmatically). + [programmatically generating Systems tutorial](@ref programmatically). ```@example nonlinear using ModelingToolkit, NonlinearSolve diff --git a/docs/src/tutorials/ode_modeling.md b/docs/src/tutorials/ode_modeling.md index 3113ab0fc2..6da2524140 100644 --- a/docs/src/tutorials/ode_modeling.md +++ b/docs/src/tutorials/ode_modeling.md @@ -362,15 +362,15 @@ memory allocations. For large, hierarchically built models, which tend to be sparse, speedup and the reduction of memory allocation can also be expected to be substantial. In addition, these problem builders allow for automatic parallelism by exploiting the structural information. For more information, see the -[ODESystem](@ref ODESystem) page. +[System](@ref System) page. ## Notes and pointers how to go on Here are some notes that may be helpful during your initial steps with MTK: - The `@mtkmodel` macro is for high-level usage of MTK. However, in many cases you - may need to programmatically generate `ODESystem`s. If that's the case, check out - the [Programmatically Generating and Scripting ODESystems Tutorial](@ref programmatically). + may need to programmatically generate `System`s. If that's the case, check out + the [Programmatically Generating and Scripting Systems Tutorial](@ref programmatically). - Vector-valued parameters and variables are possible. A cleaner, more consistent treatment of these is still a work in progress, however. Once finished, this introductory tutorial will also cover this feature. diff --git a/docs/src/tutorials/optimization.md b/docs/src/tutorials/optimization.md index d299416412..89237e01e6 100644 --- a/docs/src/tutorials/optimization.md +++ b/docs/src/tutorials/optimization.md @@ -14,7 +14,7 @@ The package can also build optimization systems. is not yet compatible with `OptimizationSystem`. We thus have to use a lower level interface to define optimization systems. For an introduction to this interface, read the - [programmatically generating ODESystems tutorial](@ref programmatically). + [programmatically generating Systems tutorial](@ref programmatically). ## Unconstrained Rosenbrock Function diff --git a/docs/src/tutorials/programmatically_generating.md b/docs/src/tutorials/programmatically_generating.md index 406f65d8d9..93a9543818 100644 --- a/docs/src/tutorials/programmatically_generating.md +++ b/docs/src/tutorials/programmatically_generating.md @@ -1,10 +1,10 @@ -# [Programmatically Generating and Scripting ODESystems](@id programmatically) +# [Programmatically Generating and Scripting Systems](@id programmatically) -In the following tutorial, we will discuss how to programmatically generate `ODESystem`s. -This is useful for functions that generate `ODESystem`s, for example -when you implement a reader that parses some file format, such as SBML, to generate an `ODESystem`. -It is also useful for functions that transform an `ODESystem`, for example -when you write a function that log-transforms a variable in an `ODESystem`. +In the following tutorial, we will discuss how to programmatically generate `System`s. +This is useful for functions that generate `System`s, for example +when you implement a reader that parses some file format, such as SBML, to generate an `System`. +It is also useful for functions that transform an `System`, for example +when you write a function that log-transforms a variable in an `System`. ## The Representation of a ModelingToolkit System @@ -28,7 +28,7 @@ eqs = [D(x) ~ y However, ModelingToolkit has many higher-level features which will make scripting ModelingToolkit systems more convenient. For example, as shown in the next section, defining your own independent variables and differentials is rarely needed. -## The Non-DSL (non-`@mtkmodel`) Way of Defining an ODESystem +## The Non-DSL (non-`@mtkmodel`) Way of Defining an System Using `@mtkmodel`, like in the [getting started tutorial](@ref getting_started), is the preferred way of defining ODEs with MTK. @@ -63,7 +63,7 @@ and passing it to the `System` constructor. `@named` automatically gives a name to the `System`, and is shorthand for ```@example scripting -fol_model = System(eqs, t; name = :fol_model) # @named fol_model = ODESystem(eqs, t) +fol_model = System(eqs, t; name = :fol_model) # @named fol_model = System(eqs, t) ``` Thus, if we had read a name from a file and wish to populate an `System` with said name, we could do: diff --git a/docs/src/tutorials/stochastic_diffeq.md b/docs/src/tutorials/stochastic_diffeq.md index 9bc0086d35..72a77eda05 100644 --- a/docs/src/tutorials/stochastic_diffeq.md +++ b/docs/src/tutorials/stochastic_diffeq.md @@ -1,6 +1,6 @@ # Modeling with Stochasticity -All previous differential equations tutorials deal with deterministic `ODESystem`s. +All previous differential equations tutorials deal with deterministic `System`s. In this tutorial, we add randomness. In particular, we show how to represent a [stochastic differential equation](https://en.wikipedia.org/wiki/Stochastic_differential_equation) @@ -13,7 +13,7 @@ as a `SDESystem`. is not yet compatible with `SDESystem`. We thus have to use a lower level interface to define stochastic differential equations. For an introduction to this interface, read the - [programmatically generating ODESystems tutorial](@ref programmatically). + [programmatically generating Systems tutorial](@ref programmatically). Let's take the Lorenz equation and add noise to each of the states. To show the flexibility of ModelingToolkit,