It means the causality is not built into the components but instead decided once your system is defined. The point is that you can make a change to the causality without having to refactor major parts of your model. It also means, even without the factoring, that the causalization (determining what is computed in terms of what) is done for you by the compiler, which spares you from doing lots of tedious, time-consuming and error prone work.
But this representation is exclusive to JuliaSim, is it not? MTK package didn't have equivalents of Dialog, Icon and Diagram annotations the last time I checked.
The Modelica Association is a non-profit that publishes the specification, the standard library and all conference proceedings for free. We sell merch in part because people in the Modelica community like the language and like to show it but also as a way to fund the not for profit activities.
Modelica allows you to create models in a similar way to spice by describing components and how they are connected. But instead of a netlist of nodes, Modelica has a concept of connectors. But otherwise it is fairly similar. However, Modelica's scope is well beyond that of Spice or Verilog-A. Those languages claim that by analogy they can do other domains but you are mainly limited to simple "equivalent" circuit models for thermal systems and their analogies to mechanical systems are (in my opinion), hopelessly flawed. Not to mention that there are high quality libraries in Modelica for modeling multibody systems and two phase fluid systems...things I would never attempt in Spice or Verilog-A.
As for Simulink...that is an entirely different beast. Simulink's focus is on modeling of dynamics using a representation of the _math_, not the physics. What this means in practice is that when you build a model you translate the text book equations into a _causalized_ mathematical representation of your system. The problem with this is that changing even very basic assumptions will require you to re-causalize the system of equations and this is quite tedious, time-consuming and error prone. The way I always describe it is that Simulink is like performing long division (you do all the tedious, time consuming and error prone work yourself) whereas Modelica is like a calculator (it does all that stuff for you and just helps you get to the answer quickly). But the key point about Modelica is that it leverages a compiler that does a ton of work for you (not just causlization but state selection, index reduction, etc). Now MathWorks has Simscape that supports this "acausal" approach that Modelica uses, but in my opinion Modelica is not only technically better and more powerful, but also more open (see OpenModelica, for example).
Well most Modelica tools generate C code. I think all of them also generate FMUs (lookup Functional Mockup Interface, if you don't know what an FMU is). Some FMUs are source code FMUs (suitable for running on HiL hardware, for example).
But it sounds like you might be talking about autocoding of an embedded controller. In that case, I'm not aware of any tools with that target. Part of this is because Modelica can be used to model the controls, the plant or both. But for autocoding you'd need a clear partitioning and some way of connecting the controls to a scheduler. But I don't know of a Modelica tool that supports this. My hope is that the next generation of tools will address this (that's part of my day job ;-)).
Interesting. Can you suggest one or two in particular? I'd be curious about that code.
And yes, I'm talking about autocoding of an embedded controller. Which also means the C code has to be ready for that (hard real time, carefully controlled calls to libraries, no heap allocation, etc.)
Right now Simulink embedded coder can be (and is) used to generate production code for all sorts of aerospace vehicles (rockets/spacecraft/drones/etc). The moment any Modelica tool can be used like this I'll take a very serious look.
The Julia tools can target embedded devices through LLVM if it has an LLVM compiler. This is one of the big reasons for the juliac ahead-of-time compilation functionalities recently added to Julia v1.12, it's for the JuliaSim/ModelingToolkit.jl simulation environments to target embedded devices in this manner. We'll be sharing something on this at the MODPROD OpenModelica conference early next year.
As for C code, we're working on it through JuliaSim. JuliaSim's modeling language is very similar to Modelica in some aspects (Mike Tiller who is in this thread and the author of many of the main Modelica teaching tools is also one of the creators of this language), though there were some breaks which were required in order to make better downstream integrations with the Julia stack and in order to modernize development workflows (integrations with package management, some new langauge features, etc.). Part of what we're trying to do is solve exactly where Modelica got stuck: embedded code generation and other "non-GUI workflows" (CI/CD for example) and making those first-class integrated with the declarative modeling language. There's still a good amount of work to do but we've already started trickling out some results in this direction and running workshops on the tools at Modelica conferences.
Modelica not only has discrete events (see other comment), it includes support for synchronous (clocked) systems of equations directly in the language. These kinds of language semantics are necessary if you want to have unambiguous discrete models.
Over 20 years ago I modeled an internal combustion engine, an automatic transmission and a multibody chassis model all in a single model. IIRC, the model had something like 250,000 equations in it and it modeled combustion, hydraulics, friction, and 3D rigid body motion. It is capable of far more than simple models.
That’s incredible, I had no idea this was even possible. Are most auto manufacturers modelling their vehicles this way? Seems like an amazing way to search for optimizations, predictive failures, etc.
It is pretty wide spread in automotive. I think nearly all F1 teams use it (hard to know for sure since they are quite secretive, but it is very common in my experience)
Yes. And "Introduction to Physical Modeling with Modelica". I also built the Modelica Playground (which I deliberately didn't link to because a thundering herd of HN readers would have crashed it).
Are you aware of any books like your "Introduction to Physical Modeling with Modelica" but for readers without a background in EE, math, physics? I am looking for something for a mediocre SWE like myself. It doesn't have to be Modelica; I could try learning MatLab or Mathematica, etc.
Well if you are interested in the intersection of software engineering and technical computing, I'd recommend Julia. I'm currently working on JuliaSim which is a Modelica like system built on top of Julia. So Julia might interest you as a programming language and then you could pick and choose what aspects of things like ModelingToolkit if you are interested in the engineering, math and physics aspect or you can just stick to the software/programming aspects of Julia.
Modelica by Example is a textbook on Modelica, not a searchable index of models. It doesn't even cover the Modelica Standard Library in any details much less the many other Modelica libraries out there. To determine if something has been done in Modelica your best bet is to Google about it. All the proceedings from all Modelica conferences are available free online and open to be crawled by any search engine. That's where you'll find what has really been done.
I actually would disagree that Bond Graphs are the "underlying mechanism" in Modelica. The Modelica community and the Bond Graph community are a bit at odds in fact. My side of this story can be found at [1] and [2]. I disagree with the idea that Bond Graphs will give you an intuitive understanding of just about every system. What it will give you is an appreciation for the elegance of the Bond Graph formulation. But the analogies drawn there are, in my experience of 30 years of modeling in industry, extremely superficial. The analogies all break down once you get past passive, linear elements (e.g., why isn't there momentum in thermal systems, what if I have an compressible fluid, what is the analogy of a clutch in an electrical system, etc). Bond Graphs also aren't really acausal either, they are just a different causal formulation that is closer to the physics.
I'm sure Bond Graph fans will disagree. I am just sharing my personal, subjective opinion here.
I studied bond graphs in modeling & simulation courses in college. I thought they were so cool! The utility knife of understanding mechanical phenomena.
