# What's all the current development of MTK currently going on related to?

**URL:** <https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286>\
**Category:** Modelling & Simulations\
**Created:** [July 16, 2026, 3:15pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286 "2026-07-16T15:15:12Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![mark.garnett](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@mark.garnett](https://discourse.julialang.org/u/mark.garnett)\
**Post date:** [July 30, 2026, 7:30pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/21 "2026-07-30T19:30:07Z")

</div>

I had not seen this thank you

---

<div class="post-metadata">

**Author:** ![hexaeder](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hexaeder/32/24403_2.png) [@hexaeder](https://discourse.julialang.org/u/hexaeder)\
**Post date:** [July 31, 2026, 5:56am UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/22 "2026-07-31T05:56:44Z")

</div>

> [@langestefan](#):
>
> Not sure how relevant this is, but [NetworkDynamics.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/NetworkDynamics) also exists, which is a backend for [PowerDynamics.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/PowerDynamics) (power system dynamics over a graph)

NetworkDynamics is more limited than GraphDynamics in the sense that we are very strickt about the “interface” between nodes and edges. Its main goal is to simulate systems which have “flows” on edges and “potentials” on nodes. While the dynamics themself can be heterogeneous (MTK models on edges and vertices, only subset of MTK supported), the interface is not (for example in PowerDynamics each edge model calculates currents based on nodal voltage, each nodal model calculates voltage based on current). Making the graph structure explicit is very good for component reuse across topologies, componentwise initialization and addressing of components/states based on their position in the network. We have some experiments for simulating gas and district heating networks with it as well (finite volume discretization along the edges, single finite volumes as nodes). But we specificially do not represent all discretization points as individual nodes in our network, a full pipe would just become a single edge model with N internal states for N finite volumes.

---

<div class="post-metadata">

**Author:** ![Bart\_van\_de\_Lint](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bart_van_de_lint/32/212161_2.png) [@Bart\_van\_de\_Lint](https://discourse.julialang.org/u/Bart_van_de_Lint)\
**Post date:** [July 31, 2026, 1:43pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/23 "2026-07-31T13:43:34Z")

</div>

So GraphDynamics seems like the more efficient way to do it: don’t discard the structure and directly use it for codegen. But it is not flexible, no index reduction etc.. So that’s where the DCP would come in as a general solution: let mtkcompile simplify the system and do all the MTK magic, and add compiler passes in codegen to reduce the equation size. @dhairyagandhi96 is there any timeline for the DCP to become publicly available? I would love to give it a try.

---

<div class="post-metadata">

**Author:** ![mark.garnett](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@mark.garnett](https://discourse.julialang.org/u/mark.garnett)\
**Post date:** [July 31, 2026, 3:07pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/24 "2026-07-31T15:07:19Z")

</div>

What are the benefits of NetworkDynamics.jl as far as scaling the system to potentially thousands of nodes and edges vs plain MTK?

This approach of edges and nodes seems to be the way. The mass conservation and energy conservation are solved at the nodes/volumes, and momentum equations on the edges.  
NASA’s Generalized Fluid System Simulation Program uses this approach and probably other commercial softwares as well.

---

<div class="post-metadata">

**Author:** ![hexaeder](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hexaeder/32/24403_2.png) [@hexaeder](https://discourse.julialang.org/u/hexaeder)\
**Post date:** [July 31, 2026, 3:32pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/25 "2026-07-31T15:32:56Z")

</div>

> [@mark.garnett](#):
>
> What are the benefits of [NetworkDynamics.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/NetworkDynamics) as far as scaling the system to potentially thousands of nodes and edges vs plain MTK?

So pre MTK@v11 the scaling of MTK systems was a much bigger problem. In NetworkDynamics our backend is not symbolic at all, its just Julia code. So our symbolic simplification and code gen stops at the component level. To make it concrete: in PowerDynamics you will normally use dynamic models like generators in the order of 5-30 states (up to ~300 eqs pre simplification maybe). The symbolic simplification pipeline only sees those equations, simplifies and emits Julia code. In the network you can then use the same compiled components 5 or 5000 times – no more symbolic handling needed. ND tries to keep lots of the benefits which come from symbolic modeling though, for example hooking into SymbolicIndexingInterface for inspecting removed/observed states of the compiled component models after solve.  
On old MTK versions modeling those kinds of systems would not have been feasible, MTK simply couldn’t scale to systems with tens of thousands equations – this might have changed in v11.

---

<div class="post-metadata">

**Author:** ![Bart\_van\_de\_Lint](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bart_van_de_lint/32/212161_2.png) [@Bart\_van\_de\_Lint](https://discourse.julialang.org/u/Bart_van_de_Lint)\
**Post date:** [July 31, 2026, 8:08pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/26 "2026-07-31T20:08:39Z")

</div>

In MTK v11 the structural simplification got much faster, but it creates one big RHS function. That just doesn’t scale well, at some point this RHS function gets very big which is very slow to compile. So I will give NetworkDynamics.jl a try.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 1, 2026, 9:31pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/27 "2026-08-01T21:31:31Z")

</div>

> [@Mason](#):
>
> I don’t mean to knock MTK here, it’s an incredible tool and I should have provided more caveats, but I thought it was clear from the context of Bart’s problem that he was also in a situation like the one Neuroblox was in where he was more using MTK as a way of composing many structurally identical building blocks together, rather than using it for it’s powerful simplification and transformation tools. For that, MTK is just not (currently) the right tool.

Looking at Bart’s model, it’s purely a mass-spring model. I.e., it’s not a multibody system with rigid bodies but instead more of a “reinforcement learning gym” type of robotics model. My assumption is that probably is an artifact of making an MWE since most Dymola-style multibody models do not simplify down to that structure, but 🤷 yeah if the MWE does match the complexity of the true system, then it would fall into the GraphDynamics sphere. Though GraphDynamics is missing some of the linearity specializations that RL gym types of simulators would focus on.

---

<div class="post-metadata">

**Author:** ![Bart\_van\_de\_Lint](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bart_van_de_lint/32/212161_2.png) [@Bart\_van\_de\_Lint](https://discourse.julialang.org/u/Bart_van_de_Lint)\
**Post date:** [August 2, 2026, 8:26am UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/28 "2026-08-02T08:26:30Z")

</div>

> [@ChrisRackauckas](#):
>
> My assumption is that probably is an artifact of making an MWE since most Dymola-style multibody models do not simplify down to that structure

Yes, but the true system also has a lot of repeated structure. The models that are slow to compile with MTK are slow because they have a lot of point masses and rigid bodies. Models with less points / rigid bodies but the same complexity are sufficiently fast to compile.

---

<div class="post-metadata">

**Author:** ![mark.garnett](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@mark.garnett](https://discourse.julialang.org/u/mark.garnett)\
**Post date:** [August 19, 2026, 2:46pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/29 "2026-08-19T14:46:02Z")

</div>

seems like some work related to handling equations in array form is being merged in, this is probably good news for scaling to large number of equations!

> <https://github.com/SciML/ModelingToolkit.jl/pull/4983>
>
> \> \[!NOTE\]
> \> Draft — please ignore until reviewed by @ChrisRackauckas.
> \> Stacked …on #4982 (\`collect\_operator\_variables\`), which supplies the correct
> \> \`differential\_vars\` this relies on.
> 
> \## Why
> 
> A finite-difference PDE discretization can emit its interior as \*\*one array equation over
> slices\*\* instead of one scalar equation per grid point, which makes the symbolic system
> size independent of grid resolution (SciML/MethodOfLines.jl#428). Measured on the 1D heat
> equation, generating code directly from such a system: \*\*1 614 expression nodes at every
> grid size, versus 20 646 → 117 446 growing\*\* for the scalarized form, with identical
> numerics.
> 
> \`mtkcompile\` scalarizes array equations, so that structure is erased before codegen.
> \`ODEProblem\` fundamentally needs it to: it requires \`D(x) = f(x)\`, and isolating the
> derivative out of a residual \*is\* structural simplification.
> 
> The implicit-DAE path does not have that requirement — a residual \`D(u) - f ~ 0\` is exactly
> what \`DAEProblem\` consumes.
> 
> \## What changed
> 
> Four changes, all inert outside the implicit-DAE path with array equations:
> 
> | | |
> |---|---|
> | \`check\_array\_equations\_unknowns\` | skipped when \`implicit\_dae\`; \*\*every other problem type keeps the guard\*\* |
> | \`check\_eqs\_u0\` | skipped only when a DAE system \*actually contains\* array equations, where an equation count is not comparable with an unknown count — scalarized DAEs keep the check |
> | \`expand\_array\_derivatives\` | rewrites \`D(u\[2:4\])\` into the scalar derivatives bound to the \`du\` argument, which a derivative of a slice otherwise matches none of |
> | \`flatten\_array\_residuals\` | expands an array-valued residual entry into one output row per element, \*\*indexing the shared expression\*\* rather than scalarizing it |
> 
> Both codegen helpers return their input unchanged when nothing is array-valued, so existing
> implicit-DAE systems generate identical code.
> 
> \## Evidence
> 
> Before this, \`DAEProblem\` on such a system failed in sequence: the array-equation guard,
> then \`Equations (3), unknowns (21)\`, then a literal \`Differential\` surviving into the
> generated code (\`MethodError: no method matching (::Differential)(::Vector{Float64})\`).
> 
> After, on the heat equation with 3 equations and 21 unknowns:
> 
> - \*\*21 output rows\*\* produced from 3 equations (81 from 3 at the larger size)
> - \`differential\_vars\` = \*\*19/21\*\* and \*\*79/81\*\* — interior differential, boundaries algebraic
> - residual evaluates finitely
> - end-to-end solve with \`DFBDF\` + \`BrownFullBasicInit\`: \*\*\`max|u - exact| = 7.57e-4\`\*\*
> against \`exp(-π²t)sin(πx)\`, the expected second-order spatial error on 21 points
> - \`ODEProblem\` on the same system still throws
> 
> \`\`\`
> Test Summary: | Pass Total Time
> arrdae | 11 11 4m16.8s
> \`\`\`
> 
> Includes a 2D case: \`expand\_array\_derivatives\` originally flattened the scalarized
> derivative with \`vec\`, which produced a length-81 vector against 9×9 surrounding slices
> and failed with \`DimensionMismatch\`. Every array equation of two or more dimensions was
> affected, and the 1D tests could not catch it because \`vec\` is a no-op there. Fixed, with
> a regression test.
> 
> \## Notes for review
> 
> - \`DAEProblem\` still needs \`build\_initializeprob=false\` here: MTK's initialization system
> builds a time-independent system and rejects the \`Differential\` inside the array
> equation. The solver's own \`BrownFullBasicInit\` covers that case, but it is only valid
> when no initialization equation constrains a derivative or an algebraic variable, so
> automating the choice needs care. Not addressed in this PR.
> - Array equations only survive \`System\` construction in \*\*residual\*\* form. Written
> naturally as \`D(u\[2:n-1\]) ~ rhs\`, \`diff2term\` fails with
> \`Can only build StableIndex{Int} from indexed symbolic\` — it cannot name a derivative
> of a slice. Worth knowing for anyone generating such systems.
> - I have not measured whether CSE hoists the shared array expression across the expanded
> rows. If it does not, the stencil is recomputed per row, which would be worse than
> scalarizing — so the performance claim above is about the \*symbolic\* representation,
> not yet about generated-code quality.
> - Tests are \`lib/ModelingToolkitBase/test/array\_equation\_dae.jl\`; I ran that file and
> \`variable\_utils.jl\`, not the full suite.
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> https://claude.ai/code/session\_01S1dxUEPGysx27SSSpxtiQ9

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 20, 2026, 3:42am UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/30 "2026-08-20T03:42:50Z")

</div>

> [@mark.garnett](#):
>
> seems like some work related to handling equations in array form is being merged in, this is probably good news for scaling to large number of equations!
> 
> [feat: accept array equations on the implicit-DAE path - Pull Request #4983 - SciML/ModelingToolkit.jl - GitHub](https://github.com/SciML/ModelingToolkit.jl/pull/4983)

Yes, MethodOfLines.jl v1 with O(n) scaling (i.e. not O(n^4) like before) should come out probably next week. Just finishing a few last things.

---

<div class="post-metadata">

**Author:** ![mark.garnett](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@mark.garnett](https://discourse.julialang.org/u/mark.garnett)\
**Post date:** [August 20, 2026, 3:30pm UTC](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286/31 "2026-08-20T15:30:40Z")

</div>

nice!

[Previous page](https://discourse.julialang.org/t/whats-all-the-current-development-of-mtk-currently-going-on-related-to/138286.md?page=1)