Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

OK, those are three quite different things.

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).



This is a fair description. I want to use Modelica but I can't get out of the Simulink ecosystem just yet.

Do you know if there's a decent C autocoding solution like that of Simulink?


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.

This renews my interest in Modelica...


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.


Thank you! Sounds like this is still in works but I'll start following its progress.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: