so even if you are just wanting to use MTK you can use that library.
Because the standard libraries are BSD3 licensed (ElectricalComponents/LICENSE.md at main · DyadLang/ElectricalComponents · GitHub) and ship with the ModelingToolkit code, they are effectively a replacement to the standard library. We haven’t deprecated the ModelingToolkitStandardLibrary but we might in the future simply because these should effectively cover the entire Modelica standard library by the end of the summer (the velocity is fast, but that’s another post )
Now in SciML we’d be happy to help maintain other MTK libraries, I think the planar dynamics thing is one that was interesting, but given this is both open source and complete we will soon start pointing to this as the preferred standard library. We’ll need to find the right way to structure the docs and such though… so it’s a bit of work to do
I read in the feature list that a goal is to make it possible to compile the software to embedded code. A few questions:
If I’m understanding this correctly, this would be a killer, killer feature. Reason being, dyad is a scripted language (unlike another very popular software out of Boston that is graphical atm), so it can be version controlled, but we can also have the benefit of programming in a signal-based programming language that boils down to C but also can become a programmable gui enviroment. Is this correct?
I’m yet to try out Dyad but will in the next couple of days, and I imagine that the best workflow is to script programs and not edit the populated gui, and rely on your software to create the graphical versions.
If my understanding is correct, how serious is your team about the compilation to embedded device feature? Like, are we talking about industrial-grade good (I’m sure your team knows of how much auto-coding is used in industry)? Reason I ask is, I’d love to try this out. For years, I’ve been saying that the Simulink vs C debate is silly and there’ll be a new language that gives the benefit of both (Dyad might be that?). Simulink is a natural environment for signals-based programming which is what you need for real life. C is not (and I love C, so no shade). C is fantastic, but for anything related to physical systems, I’d say I’d like something signals-based. But Simulink is lousy for working with modern version control, and with a team. Therefore we are left with C.
Your feedback please, thank you and best of luck with the roll-out!
There’s a one-to-one relationship between the code and GUI representation, so it doesn’t matter all that much which one is used to generate the model. The examples from the docs were actually GUI ones, were for now we stripped the placement metadata until we find a good way to hide it (in VS Code it has little arrows in the extension so it hides and you can unfold it).
We are working with partners in order to achieve DO-330 and DO-178C compatibility for the aerospace industry usage and ISO 26262 compatibility for automotive.
That is exactly the thought process behind developing a declarative language with a 1-1 mapping with the GUI representation! It sounds like you’re the target audience then and I’d be happy to chat with you more.
Note that this current release is just for Dyad Studio, which is the VS Code extension. However, the alpha release of the GUI is coming very soon though, so stay tuned, and yes this mapping between GUI and code is a core feature that is included in the first alpha (it has been one of the driving development philosophies from the start).
Superb. Getting the required certifications (ISO, DO etc) is the way to go. Yes, I’d love to jump on a call to understand the dev roadmap and possibilities here. How do we do this? I will try out the vscode extension next week.
(playground) pkg> instantiate
Updating registry at `~/.julia/registries/General.toml`
ERROR: expected package `DyadInterface [99806f68]` to be registered
Opportunity to make a “two-language solution” joke here.
I’m also curious about the choice of Typescript. Skimming the links, there’s a lot written about why Julia is used but not much about Typescript. Sorry if it’s obvious, I’m not familiar with any of this tech.
I never used commercial versions of Modelica, so my insight is limited. But in general Dyad will (hopefully) have the same advantages as MTK, as there are:
the superior solvers from the SciML ecosystem can be used
the transformation pipeline that converts the symbolical representation to the numeric problem can be extended by the user
while Modelica supports only acausal modelling, MTK (and hopefully also Dyad) also supports causal modelling
MTK has the disadvantage of lacking a GUI, this disadvantage will hopefully be fixed with Dyad.
Not only can the SciML solvers be used, but the differentiability, GPU-compatibility, etc. This makes things like training UDEs work, GPU-parallelized parameter scans, and lots of other things immediately available.
The analysis is a major departure from Modelica. In Modelica, you define your model with code, but what you do with the model is all point and click in the GUI and not standardized. You also cannot add new functionality yourself, new plots or new parameter scan samplers, or calibation methods. See the analysis interface: Write a custom analysis | Dyad . I think Modelica is an absolutely fantastic system for modeling, but where I think it did not always go far enough is what you can do with a model. In Dyad, we have focused on making that part first-class with reproducible code and a complete interface. This immediately makes things like closed loop controls analysis (Closed-Loop Sensitivity Analysis | Dyad, and soon all of DyadControlSystems.jl will be exposed through this) new features of Dyad.
Dyad has the ability to define AnalysisPoints for causalizing models. This is a crucial feature for doing interactions between causal and acausal analyses, for example performing linearizing a control system you need to define the input-output subsystem and that’s done through this. Check out the PID Autotuning on the active suspension model for example PID Autotuning Analysis | Dyad
And even further down the causal modeling tree, we are taking a different approach to synchronous programming which is better suited for targeting embedded hardware. Indeed, more to come on this in the near future.
We will have a follow-up blog post that really hammers this point home though. This is just the first of many.
Yes, for VS Code integration and also so it can run live as the GUI backend. The Dyad compiler does not do any math, just parsing, static analysis, and codegen to Julia, so it’s well-suited for that.
Hi,
Perhaps we are not speaking of the same “causal modelling”, but in my view the Modelica.Blocks standard lib along with the input and output keywords for ports fullfill that role.
Could you use a software component like GitHub - JuliaControl/DiscretePIDs.jl: Discrete-time PID controllers in Julia in Modelica? I prefer to implement discrete time controllers writing numeric code, and only doing the modelling of the physical system in continues time symbolically (using equations). Is this workflow well supported by Modelica? Can you implement a physical model that works in real-time or faster in Modelica?
That’s my feeling too (speaking with an OpenModelica UI point of view): the OMEdit/OMPlot GUI is handy to quickly inspest simulation results (more than setting up a Scope in Simulink for example), but then:
the plot configurability is UI-limited, which implies that much display logic needs to be implemented to cover many cases, which in turns increases the likelyhood of bugs (I’m having in mind here as one example the pretty long thread about OMPlot unit prefix choice)
the plotting panes configuration cannot be saved
the plot export is manual
As a work around, it’s possible to automate the simulation run and display e.g. with Python, but there is a setup & learning cost.
OK I see better your first use case: blending acausal physical models with code-based control, that is Software-in-the-Loop if I got it right. On that front, the only thing I know is the ability to inject custom C code, which is standard. I experimented this a bit 7 years ago to make a Modelica simulation exchange with “something else”, using a C code calling ZeroMQ. It was only a short experiment.
That being said, the Modelica community in a larger sense has put much effort in the FMI standard, which I’ve never used, but which is really meant for co-simulating models of heterogeneous origins.
About your second use case (“Can you implement a physical model that works in real-time or faster in Modelica?”), I think I’ve seen things on that front, but I’ve no idea how well it works. See e.g. this proof of concept published in 2012
Interesting teaser. I have the feeling that synchronous programming in Modelica was the topic of much work, implementation difficulties, and perhaps debate. I have no experience with it.
When you mean “a different approach”, do you have in mind things in the spirit of Lustre/Scade (which was recently relaunched/renamed as Scade One and the “Swan” language)? This language/environment has been taught in our engineering curriculum for several years.
We’re still working on it, so I can’t really provide too many details right now.
That said, yes, our approach is going to have a lot of the same notes (and the same synchronous foundation) as Scade or synchronous Modelica do; we think we’ve came up with a way to let you build embedded software like you do in Scade and then integrate and test that with models/interfaces that you define in an environment like synchronous Modelica affords you (along with the additional capabilities that synchronous features offer for modeling of discrete-time parts of a model).
)