# MTK: updated documentation?

**URL:** <https://discourse.julialang.org/t/mtk-updated-documentation/134937>\
**Category:** Modelling & Simulations\
**Created:** [January 7, 2026, 2:38pm UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937 "2026-01-07T14:38:42Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![BLI](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bli/32/37206_2.png) [@BLI](https://discourse.julialang.org/u/BLI)\
**Post date:** [January 12, 2026, 10:03am UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/21 "2026-01-12T10:03:27Z")

</div>

Arghhh. I can only cite Captain Alberto Bertorelli in 'Allo 'Allo: “what a mistak-e to make-e”.

As is above (with your suggested fix), I get a warning about missing initial conditions. That is fair, since I have only given guesses.

One more thing: this is not the ultimate way to do it. Most of the component share two ports/connectors (the documentation talk about pin + oneport), and it is better to introduce a “partial” component and then extend this, I guess.

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [January 12, 2026, 11:00am UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/22 "2026-01-12T11:00:47Z")

</div>

This is one of those cases where AI will immediately tell you what is wrong. For all its flaws it is pretty rock solid in detecting typos.

---

<div class="post-metadata">

**Author:** ![BLI](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bli/32/37206_2.png) [@BLI](https://discourse.julialang.org/u/BLI)\
**Post date:** [January 12, 2026, 11:09am UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/23 "2026-01-12T11:09:59Z")

</div>

A final (?) question relates to plotting…

Both of the following work:

```julia
plot(sol, idxs=(rclsys2.t*1e3, rclsys2.s2.u))

```

```julia
plot(sol, idxs=(t*1e3, s2.u))

```

**HOWEVER** , the following _does not work_:

```julia
plot(sol, idxs=(t*1e3, rclsys2.s2.u*rclsys2.r2.i))

```

while the following _does_ work:

```julia
plot(sol, idxs=(t*1e3, s2.u*r2.i))

```

I’m confused… when should I include the name of the composed/final system, and when not?

* * *

OK - I think I figured it out…

- If I have created variables on the command line/in `Main` namespace, I can address them as `t`, `s2.u`, etc.
- If I have baked them into a component, I need to prefix the variable name with the symbolic model, i.e., `rclsys2.`.
- Since `t` is imported from `ModelingToolkit`, I guess I can always refer to time as `t`?

---

<div class="post-metadata">

**Author:** ![braamvandyk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/braamvandyk/32/5086_2.png) [@braamvandyk](https://discourse.julialang.org/u/braamvandyk)\
**Post date:** [January 23, 2026, 8:21am UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/24 "2026-01-23T08:21:22Z")

</div>

Here I am going to echo what @franckgaga expressed.

I keep looking at MTK and thinking this looks amazing! Then I try to use it for work and end up saying “let’s give this a few more months.”

The code truly looks amazing, but it is just too much of a moving target to keep up with at the moment. Having the official docs falling behind this far is not helping.

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [January 23, 2026, 1:01pm UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/25 "2026-01-23T13:01:49Z")

</div>

There have been some massive changes recently, and I applaud all the hard work being put into MTK and I’m sure it will pay off in the long term. I’m hoping this year v11 will stabilize so we can start building again.

What we need most now is a solid set of well tested and documented component libraries covering all the basics in every vertical: mechanical, electrical, thermal etc. There was a discussion about it here: [ModelingToolkit V11 Library Split and Licensing, Community Feedback Requested - #89 by isaacsas](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/89)

Perhaps @isaacsas could comment on that. I think many of us including me want to help build these libraries, but right now it’s not clear what it’s going to look like.

---

<div class="post-metadata">

**Author:** ![isaacsas](https://avatars.discourse-cdn.com/v4/letter/i/f6c823/32.png) [@isaacsas](https://discourse.julialang.org/u/isaacsas)\
**Post date:** [January 23, 2026, 2:05pm UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/26 "2026-01-23T14:05:44Z")

</div>

I can’t comment on the component library issue – I’m not that involved in MTK development anymore (beyond that I work on Catalyst.jl which is tightly tied to MTK, so we often encounter issues when MTK components change that we needed for Catalyst functionality).

My limited understanding is many of the component libraries have been moved to being generated from Dyad. The resulting libraries can be used in regular Julia code too (and they are permissively licensed). I think the concern people mentioned when this was previously brought up is that since the libraries are generated via Dyad there is really no way for non-Dyad MTK users to contribute to them. But this is something that @ChrisRackauckas can much better address than me.

While MTK 11 was released, my feeling is that it is not really a release that people should update to yet. There is still a lot of activity just getting everything working in V11, and as was pointed out here, there are no official docs for it yet. If you use MTK heavily it is probably better to stay on MTK 10 for now.

---

<div class="post-metadata">

**Author:** ![BLI](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bli/32/37206_2.png) [@BLI](https://discourse.julialang.org/u/BLI)\
**Post date:** [January 23, 2026, 3:42pm UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/27 "2026-01-23T15:42:55Z")

</div>

Since I started the thread… I am super happy about all the hard work that is put into MTK. And I am looking forward to the new possibilities!

Being a “lazy” person, I tend to install the latest packages and only use them. In the current case, if I were a litter bit smarter, I should work with a version of MTK for which the documentation is correct. That is easy to do (although I am not 100% sure for which MTK model the breaks are introduced).

I am working my way through connectors and components in the new style of MTK v11, by trial and error. I have mainly figured out how to make connectors and components. What remains is the understanding of streams. Not trivial without a background from Modelica on building libraries, but I think I have cracked the problem that has bugged me for a couple of days.

Would I have progressed faster with an up-to-date documentation for MTK v11? Perhaps, I don’t know. I think understanding connectors and components also gain from some hard work.

---

<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:** [January 23, 2026, 4:02pm UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/28 "2026-01-23T16:02:23Z")

</div>

The MTK documentation has a lot of downstream dependencies on it, so in order to get the v11 docs all building those libraries need to get updated as well. There’s still some to do there, but it’s coming along. I’d say MTK v11 is in still a bit of a rollout phase, but when Catalyst is fully upgraded with it and the controls libraries are all using it, then I think we’re in a good spot.

Yes sorry this has been a pretty massive undertaking but hopefully the user-side changes aren’t so big. And hopefully we shouldn’t have other overhauls of this size: each of our major changes has been to get progressively more type inferrable, and we can now comfortably say that the whole system is type-stable and precompilable.

That doesn’t mean there isn’t much more to do of course, but hopefully this is the last time we redo the base level symbolic representation.

> [@BLI](#):
>
> I am working my way through connectors and components in the new style of MTK v11, by trial and error. I have mainly figured out how to make connectors and components. What remains is the understanding of streams.

That is all unchanged. User level is mostly unchanged except for the naming of defaults to initial\_conditions.

> [@isaacsas](#):
>
> My limited understanding is many of the component libraries have been moved to being generated from Dyad. The resulting libraries can be used in regular Julia code too (and they are permissively licensed). I think the concern people mentioned when this was previously brought up is that since the libraries are generated via Dyad there is really no way for non-Dyad MTK users to contribute to them.

That is correct, but I’ll note that the free academic license is sufficient and the standard libraries are all permissively licensed so together most people should be able to contribute.

---

<div class="post-metadata">

**Author:** ![BLI](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bli/32/37206_2.png) [@BLI](https://discourse.julialang.org/u/BLI)\
**Post date:** [January 24, 2026, 10:01am UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/29 "2026-01-24T10:01:56Z")

</div>

Good to hear that the `Stream` functionality has not changed.

One “problem” I have with Google AI Studio. At times I get an error message of type `MethodError: no method matching instream(::Float64)`. Google AI Studio insists that I then need to replace:

```julia
mtkompile(sys)

```

with

```julia
sys_1 = complete(sys)

# 1. Expand connections while variables are still symbolic
sys_2 = expand_connections(sys_1)

# 2. Only now do we simplify (which converts parameters to numbers)
sys_3 = structural_simplify(sys_2)

```

But my experience is that this has no effect in my case, and rather that the error message is due to some structural error in my code.

Is Google AI Studio correct, or is this some hallucination?

---

<div class="post-metadata">

**Author:** ![baggepinnen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/baggepinnen/32/693_2.png) [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)\
**Post date:** [January 24, 2026, 10:22am UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/30 "2026-01-24T10:22:14Z")

</div>

> [@BLI](#):
>
> Is Google AI Studio correct, or is this some hallucination?

That’s bad advice, it is outdated at best. `mtkcompile` does all those things.

---

<div class="post-metadata">

**Author:** ![BLI](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bli/32/37206_2.png) [@BLI](https://discourse.julialang.org/u/BLI)\
**Post date:** [January 24, 2026, 11:56am UTC](https://discourse.julialang.org/t/mtk-updated-documentation/134937/31 "2026-01-24T11:56:51Z")

</div>

Thanks.

One reason for getting this `instream` error came from the following…

I consider a tank system consisting of 3 tanks. One of those tanks needs 3 ports, the other 2 need 2 ports. Google AI Studio recommended me to only implement a tank with 3 ports, and to simply leave the unnecessary port (for 2 tanks) un-connected, claiming that the unconnected port would default to being “plugged”.

This gave the error message. If I instead create a `Plug` component and connect this to the “un-necessary” port, then the code works.

[Previous page](https://discourse.julialang.org/t/mtk-updated-documentation/134937.md?page=1)