Modelica | Hacker News Reader

Modelica

en.wikipedia.org

57 pointsImmortalin12 comments

Modelica sees a lot of use in building energy simulation [0], [1].

My impression is that the solver landscape is a little uneven (the solver reads a Modelica model and computes its solution). For one thing, open-source solvers seem to lag behind the commercial implementations, in terms of capabilities. Even with commercial solvers, there seems to be a non-negligible amount of work around taking correct models that don't run, and reformulating them to let the solvers run them. Caveats -- I don't work on this personally, but know people in my division who do. Also, these impressions are a few years old, and doubtless the situation is improving as time goes on.

[0] Library of component modules for building energy and control systems (http://simulationresearch.lbl.gov/modelica/)

[1] "Spawn of EnergyPlus", a prototype next-gen whole-building energy solver (https://energy.gov/eere/buildings/downloads/spawn-energyplus...)

It's a fascinating example of "near-programming", computing results declaratively, if I'm understanding the wiki. I'm actually surprised it works at all.

I have used Modelica for some classes. It works really well. You can simulate continuous and discrete time systems all in the same model. It it has some similarities to Mathworks' Simulink and Wolfram SystemModeler actually uses the Modelica language.

> I'm actually surprised it works at all.

Why?

I wouldn't expect it to find a stable solution.

I've been interested in Modelica for some time and didn't know if someone could answer a few questions. I'm interested in building what I call nodal models, but basically these are things like multiphysics models similar to circuits. Essentially, this is the bond graph methodology, but I don't think the bond graph notation is strictly necessary, so really it's just hooking things like electrical circuit models with thermal or mechanical components. Anyway, my questions are:

1. Does anyone know the history of these software tools? From what I've been able to gather, before Modelica people used ACSL (https://en.wikipedia.org/wiki/Advanced_Continuous_Simulation...), but currently products like Simulink or Amesim are more common.

2. I thought that the modern packages moved from traditional integrators like Runge-Kutta methods to QSS methods. In the applied math world/ODE/PDE world, I've never seen anyone use a QSS method. Are QSS methods general and how do they compare practically to more traditional explicit time integrators?

Anyway I'm glad to see Modelica get posted and thanks in advance for answering the questions above.

1. Yes you can say that Modelica has some heritage from ACSL. (See https://www.modelica.org/publications/papers/esm98his.pdf) but the short story is that some simulation language creators decided to form a uniform modeling and simulation language together instead of working on their own initiatives, resulting in Modelica.

2. Not really. Usually modified versions of DASSL/CVODES and friends are used by Modelica tools. In Cellier and Kofmans's book on simulation QSS gets prominent display and some of the research at Berkley Labs has been using QSS to some extent, but it is far from mainstream.

Are QSS methods general and how do they compare practically to more traditional explicit time integrators?

The original idea of QSS was to bolt an ad hoc step length control mechanism onto the most basic explicit method, forward Euler. So at its core, the original QSS method is exactly a traditional explicit integration, except that the length of any individual step is not adjusted based on feedback about how well the step actually did.

Why would you do that? The motivation was to enable parallel execution of large modularly-composed systems, without getting bogged down with iterations. Basically every important design decision in QSS methods comes directly from, or is at least deeply influenced by, the desire to avoid iterations between components in the simulation. They want to avoid large communication overheads, and they want to enable components to step forward in time as independently of each other as possible. The dream is to enable the simulation of large systems by just connecting components together, and letting each one broadcast what it plans to do over the next time step, and how long it will do it. Thus the core idea of QSS is to choose the step length a component can take before it takes the step, and to not get too inquisitive about how well the step actually did.

I always thought that QSS methods would benefit from adapting a trust region approach to at least control errors going forward in time, but as far as I know, they never did.

By the way, later versions of QSS introduced some implicit-flavored methods. I believe they are still only implicit in the local information (i.e., only state variables defined within a component get an implicit model), and that state variables defined in other, communicating, components still have an unchanging, forward-projected model. However, it's been a long time since I looked at those methods, and I might be wrong about that.

If you're interested in circuit-like systems, Modelica is probably a good fit. Electrical networks seem to be a core use case for the developers/presenters of Modelica. Also I know it has been used to model airflow networks in buildings, using the multizone approach which typically uses a nodal formulation.

If you've read much about Modelica, you probably know this, but one key to thinking about Modelica is to recognize that you're not defining a nodal system anymore -- at least, not in the way that an electrical engineering textbook would define it. Yes, you can define a network, which can have resistive/capacitive/inductive elements strung between nodes. However, in EE-speak, you would then form either the nodal equations or the mesh equations, depending on whether you wanted to add up currents into nodes, or voltages around loops. But in Modelica, you just state the component relations, and the rules that apply to the connections between components. Then the solver decides how to set up the system equations. Typically the solver uses graph-theoretical techniques to reduce the number of unknowns, or to achieve other nice system properties. So for example if you had a bunch of components in series, you might expect the common current to be a state variable, whereas in another part of the system you might find voltage state variables. Modelica encourages you to think about the components, and let the solver handle the system assembly and solution.

I believe Modelica got its start in the automotive simulation world, where there is a need for large-scale lumped-parameter multiphysics models. I'm not sure how ACSL fits in. In the building simulation world, there was also an earlier language called Neutral Model Format that attacked many of the same problems as Modelica.

It's been a long time since I studied bond graphs, but I would say Modelica is much more general, since it allows discrete as well as continuous components, and since it doesn't require the formalism of identifying the equivalent of voltages and currents in each domain (don't remember what bond graph theory calls those). I think Modelica even allows components to be defined by algorithms, although obviously those components may not have mathematical inverses that can be easily manipulated when assembling the system.

For anyone interested, the OpenModelica compiler is available, and aims to be the standard reference implementation: https://openmodelica.org

I have a friend who is or used to help define this thing, it's incredibly fiddly: mixed domain/mixed energy/correct units*correct representation types, and has to produce a result.

It looked like a way to make a closed ecosystem where there were only a few entrants (users) and the cost of entry was high both economically and in terms of the learning curve.

It is nice to see that I'm not entirely wrong.

Reply on news.ycombinator.com