Skip to content

Commit 00ea6ba

Browse files
ChrisRackauckasChrisRackauckas
committed
add comparison page and internals
1 parent 2893973 commit 00ea6ba

File tree

3 files changed

+144
-1
lines changed

3 files changed

+144
-1
lines changed

‎docs/make.jl

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -32,7 +32,9 @@ makedocs(
3232
"systems/ControlSystem.md",
3333
"systems/ReactionSystem.md",
3434
"systems/PDESystem.md",
35-
]
35+
],
36+
"comparison.md",
37+
"internals.md"
3638
]
3739
)
3840

‎docs/src/comparison.md

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
# Comparison of ModelingToolkit vs Equation-Based Modeling Languages
2+
3+
## Comparison Against Modelica
4+
5+
- Both Modelica and ModelingToolkit.jl are acausal modeling languages.
6+
- Modelica is a language with many different implementations, such as
7+
[Dymola](https://www.3ds.com/products-services/catia/products/dymola/) and
8+
[OpenModelica](https://openmodelica.org/), which have differing levels of
9+
performance and can give different results on the same model. Many of the
10+
commonly used Modelica compilers are not open source. ModelingToolkit.jl
11+
is a language with a single canonical open source implementation.
12+
- All current Modelica compiler implementations are fixed and not extendable
13+
by the users from the Modelica language itself. For example, the Dymola
14+
compiler [shares its symbolic processing pipeline](https://www.claytex.com/tech-blog/model-translation-and-symbolic-manipulation/)
15+
which is roughly equivalent to the `dae_index_lowering` and `structural_simplify`
16+
of ModelingToolkit.jl. ModelingToolkit.jl is an open and hackable transformation
17+
system which allows users to add new non-standard transformations and control
18+
the order of application.
19+
- Modelica is a declarative programming language. ModelingToolkit.jl is a
20+
declarative symbolic modeling language used from within the Julia programming
21+
language. Its programming language semantics, such as loop constructs and
22+
conditionals, can be used to more easily generate models.
23+
- Modelica is an object-oriented single dispatch language. ModelingToolkit.jl,
24+
built on Julia, uses multiple dispatch extensively to simplify code.
25+
- Many Modelica compilers supply a GUI. ModelingToolkit.jl does not.
26+
- Modelica can be used to simulate ODE and DAE systems. ModelingToolkit.jl
27+
has a much more expansive set of system types, including nonlinear systems,
28+
SDEs, PDEs, and more.
29+
30+
## Comparison Against Simulink
31+
32+
- Simulink is a causal modeling environment, whereas ModelingToolkit.jl is an
33+
acausal modeling environment. For an overview of the differences, consult
34+
academic reviews such as [this one](https://arxiv.org/abs/1909.00484). In this
35+
sense, ModelingToolkit.jl is more similar to the Simscape sub-environment.
36+
- Simulink is used from MATLAB while ModelingToolkit.jl is used from Julia.
37+
Thus any user defined functions have the performance of their host language.
38+
For information on the performance differences between Julia and MATLAB,
39+
consult [open benchmarks](https://julialang.org/benchmarks/) which demonstrate
40+
Julia as an order of magnitude or more faster in many cases due to its JIT
41+
compilation.
42+
- Simulink uses the MATLAB differential equation solvers while ModelingToolkit.jl
43+
uses [DifferentialEquations.jl](https://diffeq.sciml.ai/dev/). For a systematic
44+
comparison between the solvers, consult
45+
[open benchmarks](https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packages.html)
46+
which demonstrate two orders of magnitude performance advantage for the native
47+
Julia solvers across many benchmark problems.
48+
- Simulink comes with a Graphical User Interface (GUI), ModelingToolkit.jl
49+
does not.
50+
- Simulink is a proprietary software, meaning users cannot actively modify or
51+
extend the software. ModelingToolkit.jl is built in Julia and used in Julia,
52+
where users can actively extend and modify the software interactively in the
53+
REPL and contribute to its open source repositories.
54+
- Simulink covers ODE and DAE systems. ModelingToolkit.jl has a much more
55+
expansive set of system types, including SDEs, PDEs, optimization problems,
56+
and more.
57+
58+
## Comparison Against CASADI
59+
60+
- CASADI is written in C++ but used from Python/MATLAB, meaning that it cannot be
61+
directly extended by users unless they are using the C++ interface and run a
62+
local build of CASADI. ModelingToolkit.jl is both written and used from
63+
Julia, meaning that users can easily extend the library on the fly, even
64+
interactively in the REPL.
65+
- CASADI includes limited support for Computer Algebra System (CAS) functionality,
66+
while ModelingToolkit.jl is built on the full
67+
[Symbolics.jl](https://github.com/JuliaSymbolics/Symbolics.jl) CAS.
68+
- CASADI supports DAE and ODE problems via SUNDIALS IDAS and CVODES. ModelingToolkit.jl
69+
supports DAE and ODE problems via [DifferentialEquations.jl](https://diffeq.sciml.ai/dev/),
70+
of which Sundials.jl is <1% of the total available solvers and is outperformed
71+
by the native Julia solvers on the vast majority of the benchmark equations.
72+
In addition, the DifferentialEquations.jl interface is confederated, meaning
73+
that any user can dynamically extend the system to add new solvers to the
74+
interface by defining new dispatches of solve.
75+
- CASADI's DAEBuilder does not implement efficiency transformations like tearing
76+
which are standard in the ModelingToolkit.jl transformation pipeline.
77+
- CASADI supports special functionality for quadratic programming problems while
78+
ModelingToolkit only provides nonlinear programming via `OptimizationSystem`.
79+
- ModelingToolkit.jl integrates with its host language Julia, so Julia code
80+
can be automatically converted into ModelingToolkit expressions. Users of
81+
CASADI must explicitly create CASADI expressions.
82+
83+
## Comparison Against Modia.jl
84+
85+
- Modia.jl is a Modelica-like system built in pure Julia. As such, its syntax
86+
is a domain-specific language (DSL) specified by macros to mirror the Modelica
87+
syntax.
88+
- Modia's compilation pipeline is similar to the
89+
[Dymola symbolic processing pipeline](https://www.claytex.com/tech-blog/model-translation-and-symbolic-manipulation/)
90+
with some improvements. ModelingToolkit.jl has an open transformation pipeline
91+
that allows for users to extend and reorder transformation passes, where
92+
`structural_simplify` is an adaptation of the Modia.jl-improved alias elimination
93+
and tearing algorithms.
94+
- Modia supports DAE problems via SUNDIALS IDAS. ModelingToolkit.jl
95+
supports DAE and ODE problems via [DifferentialEquations.jl](https://diffeq.sciml.ai/dev/),
96+
of which Sundials.jl is <1% of the total available solvers and is outperformed
97+
by the native Julia solvers on the vast majority of the benchmark equations.
98+
In addition, the DifferentialEquations.jl interface is confederated, meaning
99+
that any user can dynamically extend the system to add new solvers to the
100+
interface by defining new dispatches of solve.
101+
- ModelingToolkit.jl integrates with its host language Julia, so Julia code
102+
can be automatically converted into ModelingToolkit expressions. Users of
103+
Modia must explicitly create Modia expressions within its macro.
104+
- Modia covers DAE systems. ModelingToolkit.jl has a much more
105+
expansive set of system types, including SDEs, PDEs, optimization problems,
106+
and more.
107+
108+
## Comparison Against Causal.jl
109+
110+
- Causal.jl is a causal modeling environment, whereas ModelingToolkit.jl is an
111+
acausal modeling environment. For an overview of the differences, consult
112+
academic reviews such as [this one](https://arxiv.org/abs/1909.00484).
113+
- Both ModelingToolkit.jl and Causal.jl use [DifferentialEquations.jl](https://diffeq.sciml.ai/stable/)
114+
as the backend solver library.
115+
- Causal.jl lets one add arbitrary equation systems to a given node, and allow
116+
the output to effect the next node. This means an SDE may drive an ODE. These
117+
two portions are solved with different solver methods in tandem. In
118+
ModelingToolkit.jl, such connections promote the whole system to an SDE. This
119+
results in better accuracy and stability, though in some cases it can be
120+
less performant.
121+
- Causal.jl, similar to Simulink, breaks algebraic loops via inexact heuristics.
122+
ModelingToolkit.jl treats algebraic loops exactly through algebraic equations
123+
in the generated model.

‎docs/src/internals.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
# Internal Details
2+
3+
This is a page for detailing some of the inner workings to help future
4+
contributors to the library.
5+
6+
## Observables and Variable Elimination
7+
8+
In the variable "elimination" algorithms, what is actually done is that variables
9+
are removed from being states and equations are moved into the `observed` category
10+
of the system. The `observed` equations are explicit algebraic equations which
11+
are then substituted out to completely eliminate these variables from the other
12+
equations, allowing the system to act as though these variables no longer exist.
13+
14+
However, as a user may have wanted to interact with such variables, for example,
15+
plotting their output, these relationships are stored and are then used to
16+
generate the `observed` equation found in the `SciMLFunction` interface, so that
17+
`sol[x]` lazily reconstructs the observed variable when necessary. In this sense,
18+
there is an equivalence between observables and the variable elimination system.

0 commit comments

Comments
 (0)