michaeltiller

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.

It is exclusive to JuliaSim. But the tools generate MTK compatible component models so, once built, they can be used with MTK.

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)

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.

Modelica by Example is the most recent and free, so I would recommend that.

JuliaSim does have graphical representation, a GUI and an IDE. But, granted, it is also a commercial product, not open source.

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

Just to be clear, there is absolutely nothing "corporate" about that web site. It is a non-profit organization.

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

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 is nearly 30 years old, BTW.

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

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.

https://specification.modelica.org/maint/3.6/synchronous-lan...

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.

https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...

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.

[1]: https://www.linkedin.com/feed/update/urn:li:ugcPost:72725163... [2]: https://mbe.modelica.university/components/connectors/simple...

That's an interesting way of framing it. I tend to agree. It isn't so much the presence of the type system so much as the fact that the compiler is given sufficient information (much of it symbolic) to aggressively optimize the generated code. So it seems to share that with Haskell, yes.

Chris, I agree that the symbolic processing is quite important. I've often made the argument that a purely numerical approach just can't compete because of the optimizations and insights that come out of the symbolic analysis will always put it on a better footing (curious to know if you agree). But I'd say another factor in the success of Modelica is the ability to make it approachable by non-programmers. All the graphical aspects, acausal semantics, etc. make it easy to understand for non-programmer engineers as well. This has nothing to do with the results, per se, but is I think a factor in its success.

FYI, it is by the same people who initiated the Modelica effort (Hilding Elmqvist and Martin Otter). I think part of the goal was to shed having to maintain a whole language (and the need to specify all the semantics details of such) and simply leverage a language that had macros.

I haven't really heard many updates on this in some time. I don't think it is necessarily a bad idea. But any effort along these lines takes a lot of dedicated people quite a while to make progress (as was the case with Modelica).

But, of course, what is solvable changes and/or is implementation dependent. Modelica doesn't say much on the topic of impulses. In theory, a vendor could support variable index systems along with the ability to resolve impulses. It is a conscious decision not to codify contemporary constraints on solvers/methods into the language. Of course, Sebastien Furic did quite a bit of work along the lines you are describing but he was unable to persuade the group to accept such constraints.

Very true. But I think it is important to understand the alternative.

The "object-oriented" part of Modelica is intended to make creating large scale models manageable. You make it sound like the object-oriented features are some kind of facade behind which all kinds of peril lies. But the peril is always there. And my experience of building such models both using a modeling language vs. creating them by hand is that you can't escape the limitations of contemporary numerical/symbolic methods or singular systems. You are, of course, free to hand code models or manually transform them into state space equations if you think there is some benefit to that in the same way. Perhaps it will make it easier to diagnose singular systems. But speaking entirely for me, I find being able to create acausal models using a modeling language gives me a productivity boost that I'd be unwilling to give up.