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.
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.
A final (?) question relates to plotting…
Both of the following work:
plot(sol, idxs=(rclsys2.t*1e3, rclsys2.s2.u))
plot(sol, idxs=(t*1e3, s2.u))
HOWEVER, the following does not work:
plot(sol, idxs=(t*1e3, rclsys2.s2.u*rclsys2.r2.i))
while the following does work:
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…
Main namespace, I can address them as t, s2.u, etc.rclsys2..t is imported from ModelingToolkit, I guess I can always refer to time as t?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.
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
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.
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.
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.
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.
That is all unchanged. User level is mostly unchanged except for the naming of defaults to initial_conditions.
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.
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:
mtkompile(sys)
with
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?
That’s bad advice, it is outdated at best. mtkcompile does all those things.
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.