> Modelica is a high-level declarative language for describing mathematical behavior. It is typically applied to engineering systems...
We use Modelica quite a bit in HVAC industry. In my case (controls engineer), I can request FMUs of various components from systems engineers for optimization work. (Functional Mockup Unit (FMU)[1]: stand-alone binary representing a dynamical system that can be driven by another application). My background is in Reinforcement learning/Model predictive control/python. Having a physics-driven model written in a domain-specific language which I can embed into my python workflow [2] is convenient.
I will say, Modelica requires a different perspective from "regular" imperative programming (python/matlab). It is a declarative language: you define equations, variables, constraints for a system, regardless of order. The compiler decides how to run the simulation; which variables to solve first etc.
While OpenModelica[3] has come a long way towards making an open source implementation of the language standard, proprietary applications (Dymola) still have an edge in the industry.
Another up-and-coming solution is Julia's simulation ecosystem [1]. It is powered by the commercial organization behind the Julia programming language, which has received DARPA funding [2] to build out these tools. This ecosystem unifies researchers in numerical methods [3], scalable compute, and domain experts in modeling engineering systems (electrical, mechanical, etc.) I believe this is where simulation is headed.
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.
MATLAB/Simulnk is imperative. They have signal flow/causal approach. So you should know ahead of time which variable causes another variable to change i.e. which is defined first.
Modelica is acausal. You define the variables and how they are related (equations). The compiler handles variable dependencies and resolution internally.
There are pros & cons of each. Both are used for simulating cyber-physical systems.
I seem to have a problem understanding "acausal". Is its meaning "not causal"? To me that wouldn't make much sense and sounds like another buzzword. The software still runs inside a computer. Everything inside of it is causal. And nust because the compiler decides in what order to do what, that also doesn't make it not causal, since surely the compiler follows some well known rules that _cause_ it to decide this way or that way. And surely defining relations _is_ in a way defining the causal ... relations.
So what is really the meaning of "acausal" in this context?
It's like the difference between an imperative framework and a declarative one. In a causal modeling system you as the user are responsible for writing out the causality of your model. In an acausal system, you write what components you have and how they connect and part of the compilation process is "causalization" i.e. taking the elements and connections and inferring from that the direction of causality.
This makes modeling much easier because causality doesn't compose. Adding a new component to a model can totally change what the optimal causalization is, so using an acausal framework the compiler will figure that out, but in a causal framework the user has to re-derive the causality of their model.
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.
This is a pretty niche acausal language, and is used extensively in Motorsports (F1, NASCAR) for real-time simulation on the driver simulator.
The language spec is open source but there many commercial compilers, Dymola is the most popular.
I code in this language extensively and its acausal nature is extremely powerful. It makes your models highly composable, you can basically assemble a mechanical system like a bunch of lego blocks and the equations fall out automatically. You can also easily invert your models.
The closest analogy in the programming world is Haskell.
This approach seemed super interesting and we attempted to use it for modeling a fairly complicated fluid system (pipes, valves, tanks, etc). However, in the end the equations that fell out made the solver choke. We abandoned the effort since it seemed like an undebuggable black box. It's unclear to me whether we just didn't do it right or if the open source alternatives just aren't capable.
Think of it like a solver for many coupled differential equations.
The coupling happens through "linear" equality constraints.
Such as "the output pressure variable of component A needs to be equal the input pressure variable of component B".
Something that Modelica doesn't do very well is stochastic systems. There you would need to go into SDE and that brings a lot of technicalities.
[1] Petzold, Linda R. Description of DASSL: a differential/algebraic system solver. No. SAND-82-8637; Sandia National Labs, 1982.
[2] Kunkel, Peter. Differential-algebraic equations: analysis and numerical solution. European Mathematical Society, 2006.
As someone who has no idea what this is about bar the landing page explanation, and isn't in this space -- it would be great if the front page had examples, or links to examples.
30 seconds of clicking around and I've failed to find sth compelling.
As someone who is a curious outsider to Modelica, it piqued my interest a few years ago when I found out that this language lets you write equations more directly than most other programming languages. Take the ideal gas law, for example, PV = nRT, which has 5 identifiers. In most programming languages, you'd have to keep only one variable to the left, that is assigned to, e.g. T=PV/nR, and a similar set of equations if you want to determine any of the other variables, given the rest. In Modelica, the same equation, expressed as you would in natural math, works for determining the unknown, based on the knowns.
This is generally referred to as an acausal modeling environment - you don't need to bring the causality of mathematical relationships, just bring the relationships.
There are several other tools in this space, not the least prevalent of which is Mathworks' Simscape product line [1]. Wolfram has a solution that is also very similar to Modelica [2]. Finally, I believe that you will find ModelingToolkit.jl [3] worth a look (along with Julia in general) if your interest is piqued here by Modelica. I believe MTK is a big slice of the future of acausal modeling tools.
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.
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.
Downvoted but relevant...nothing says corporate bullshit like a niche programming language with logos and merch featured far more prominently than examples or explanation...
Another day, another nondescript product name on HN for Russian roulette clicking. Dare to say anything about it, get downvoted into a smoking hole in the ground (e.g. by webdevs who assume everyone else is), yadda yadda... I'm pretty convinced by now that it will never change.
There’s not a single example on the landing page. There’s not a single example on any of the main links from the landing page.
But the landing page does have a merch store so you can buy mugs and hoodies and look at huge company logos of “organizational members”, whatever that is.
You made something. Show me what you made. I’m probably not going to spend more than 30 seconds trying to figure it out unless I already know I need it.
Modelica is is in wide use in many industries, just not yours apparently. This is kinda like linking to Java or C++ and then being surprised it doesn’t have a top level intro explaining how to use it.
That doesn't mean anything to somone who doesn't already know what Modelica is. It would be hard to be more vague. C++ technically satisfies that definition.
I am now using Modelica with OpenModelica at work to describe electromagnetic systems and it is an excellent language and, with OpenModelica, a excellent graphical user environment. Sometimes I think of it like SPICE but for multi-physics systems.
The Modelica library is quite mature and complete and the numerical solvers included with OpenModelica robust and performing.
It looks me a while to learn it but now it is paying out.
In addition the fact that Modelica is a standard implemented by several suppliers with an open source application is also great to avoid vendor lock in so that is a technology on which is safe to invest as an engineer and as a company.
Modelica is an excellent way to perform these simulations. Exporting a functional mock-up unit (FMU) according to the FMI standard is a first-class capability [1] that is another huge source of value, especially for systems integrators. You are able to have reasonably obfuscated models of your system in untrusted hands, and they get the full benefit of your system model. This is one area where OpenModelica is ahead of competitors including the open-source ModelingToolkit.jl [2] and related library FMIExport.jl [3].
I remember using OpenModellica to test an Functional Mockup Unit where I extracted Neural Net as ONNX and the ONNX runtime DLL and then connected it to Simcenter Amesim as my student work at Siemens. Pretty okay standard compared to how old and crusty the APIs of engineering software are.
I finished university 4 years ago but just now I am going down the rabbit hole of bond graph modeling and studying directly from the MIT class notes of Henry M. Paynter [1] while simultaneously using Simscape at work for modeling vehicle systems. I understand that bond graphs are the underlying mechanism upon which Modelica and Simscape are built upon(?).
Can any expert in this field give me some pointers. My current belief is that understanding the theory of bond graphs will give me intuitive understanding of just about every system I work with in my field.
I find that this field is surprisingly niche, as most of my peers have never paid special attention to it, but when I found about it, it seemed to me like a magic bullet for all my problems.
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.
So, IIUC, this is a language to describe, in a rather general manner, a "system", which can either be modeled via differential equations and/or discrete equations (if/then/else).
This is very nice, especially if it is general enough.
However, what is even more interesting is the general methodology to actually run the time-based simulation of such a system, especially if this allows to describe arbitrarily complex diffeqs (other than brute force monte-carlo style integration/sampling).
Obligatory mention to Openmodelica[1] which is an open source implementation based on the Modelica language. While I haven't used it yet, I was planning on exploring some of the features this holiday.
There is also a project by Hilding Elmqvist, who worked for Dassault on Dymola (the leading commercial implementation of Modelica). His project is Modia.jl:
I can personally feel the Julia community settling on MTK, but Modia was ahead in the early stages of dynamic system simulation in Julia, and I believe MTK has drawn a lot of inspiration from each Modia and Modelica. Modia is a bit more ergonomic while also being the first to integrating things like 3D viewers and a complete multibody package by years, with Julia Computing only now catching up [1]. MTK has a better support for back-end solvers and holds a lot of promise to leapfrog Modia, especially since the release cadence for Modia seems to have slowed.
In fact Dymola was published (including source code) in Hilding Elmqvist's doctoral thesis:
Elmqvist, H. (1978). A Structured Model Language for Large Continuous Systems. [Doctoral Thesis (monograph), Department of Automatic Control]. Department of Automatic Control, Lund Institute of Technology (LTH).
Having used it in the work. My 2 cts about the not free version: KEEP AWAY. RUN! Cannot do much more than any free SPICE, complex licensing, buggy. Is just like the LabVIEW of simulations.
One of the advantages Dymola had a few years ago was an extremely advanced vehicle dynamics toolbox, to the point where it is considered a standard for NASCAR [1]. This is one of the tool's originating claims to fame circa 2015-19 when I was bringing it into a previous employer in the automotive industry. For some applications that are "first class", you will have a great experience with Dymola. Where they have filled in the blanks in toolboxes, however, you are likely not a cut above other tools.
Together with colleagues, I have been developing the dynamical systems modeling language "NESTML" for hybrid dynamical systems, that is, systems that contain continuous-time dynamics (expressed as ordinary differential equations) as well as being able to emit and receive discrete events that happen instantaneously in time. We strive for a minimal syntax, so you can write a model really concisely, for example:
model lorenz_attractor:
state:
x real = 1
y real = 1
z real = 1
equations:
x' = sigma * (y - x) / s
y' = (x * (rho - z) - y) / s
z' = (x * y - beta * z) / s
update:
integrate_odes()
parameters:
sigma real = 10
beta real = 8/3
rho real = 28
For events, there are constructs like "onReceive(in_port_name)" and "emit_spike()" (nomenclature there being clearly somewhat influenced from our neuroscience application domain).
I was frankly surprised that something like this did not already exist when I started development on NESTML. Modelica is similar, but does not seem to have support for discrete events. I realise all of this is a shameless plug ;) but in actuality we are of course very happy to receive comments and feedback! All development is out in the open on GitHub and it is GPL licensed. If someone knows of similar DSLs, I would be very happy to read your comments. Cheers!
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.
I don't think that System Dynamics modelling tools offer the depth of control over the governing equations that Modelica has. In addition, Modelica has a nice standard library with many physical components that you can link together to form a system.
In short, Modelica is better for simulation well-specified physical systems. System Dynamics is good for simulating the approximate behaviour of larger, often poorly understood systems.
Modelica can absolutely be used for this, but there may not be a readily-available model created already. A generic stepper motor model is available here:
Operationalizing this into a Modelica model is pretty straightforward. Did not look for a driver model, but a driver model would be a lot more important in modern times. I am guessing that not many people would simulate this fidelity of stepping dynamics as a "first cut", and anyone who does is likely to also have a detailed driver model. Demand for this model in a standard library is likely quite small.
You could use it to model a CNC machine, but you'd probably need to make new components. It would also be difficult to model the changing load as the spinning tool plunges into metal, but you could model dynamic deformation and response of the machine given the loads. It is difficult to model changing 3D contacts in modelica, although a new approach to solving newton's equations, dialectic mechanics may fix this problem
NEMA isn't a type of motor, it's a connection standard used for motors. You might be able to model stepper motors with some of the components in the modelica standard library for magnetic modeling.
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.
The concept of FMUs is pretty interesting if you work in simulation, but I was surprised how terrible the third party support is.
There is not a single third party way to generate a Model Exchange FMU for Linux, using anything but the very badly designed C reference FMUs or some commercial project. Even Matlab has poor support for it.
People seem to be comparing it to Simulink, but to me the language seems to have more in common with matlab / octave's symbolic package / python's sympy.
The difference you are pointing to is the acausal vs causal description. In Simulink (Causal), you have to describe what causes any changes in the system. For example, to model Ohm's law, you'd write something like I=V/R. Which translates to the current obtained when some potential difference is applied across a resistor. So I is a function of V in this respect and you can say V causes I in R.
In Acausal systems like modelica, it does not matter whether you write V=IR or any alternate formulation. You simply provide the description and it is up to the compiler to obtain the relevant set of equations that can be fed into the ODE solver. The advantage being that you spend less time fitting your problem into the causal framework required by Simulink or alternates where, when you change your model, you end up doing significant rewrites.
TL;DR: Causal descriptions take more time to arrange as compared to Acausal.
"In which case, isn't comparing it to Simulink instead of Sympy a bit ... odd?"
No, as it is not used as Sympy. Modelica is used to model physical systems in a composable way with graphical representation of connections between components. Many people use Simulink for that, so this is why it is compared with it.
Sympy is a nice project, but is applied in a different context, definitely not to model systems with thousands of equations in the industrial setting (that would be painful).
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.
You can do a lot of the same kinds of things with Verilog-AMS and VHDL-AMS. Generally with simulators there's a kind of analog to the Turing tarpit - it's not "can I model this thing I know how to model with differential equations?" but what tooling, graphical tools, optimizers, synthesizers, libraries, etc are available.
Hey folks!
If you're into trying out bleeding-edge technologies, check out the MARCO compiler. We're focusing on optimizing large-scale systems, and it's already showing significant improvements compared to existing solutions.
That said, we're still in the early stages: language support needs to grow, and for now, there's only a command-line interface. But hey, it's open-source, so contributions, feedback, or feature requests are more than welcome!
> Modelica is a high-level declarative language for describing mathematical behavior. It is typically applied to engineering systems...
We use Modelica quite a bit in HVAC industry. In my case (controls engineer), I can request FMUs of various components from systems engineers for optimization work. (Functional Mockup Unit (FMU)[1]: stand-alone binary representing a dynamical system that can be driven by another application). My background is in Reinforcement learning/Model predictive control/python. Having a physics-driven model written in a domain-specific language which I can embed into my python workflow [2] is convenient.
I will say, Modelica requires a different perspective from "regular" imperative programming (python/matlab). It is a declarative language: you define equations, variables, constraints for a system, regardless of order. The compiler decides how to run the simulation; which variables to solve first etc.
While OpenModelica[3] has come a long way towards making an open source implementation of the language standard, proprietary applications (Dymola) still have an edge in the industry.
[1]: https://fmi-standard.org/
[2]: https://fmpy.readthedocs.io/en/latest/
[3]: https://openmodelica.org/