Debug Modelica code

Question

I wonder if there a way to "debug" a modelica code, I mean debugging the code line by line and you can see how variables change, things like that?

I know that the modelica code is translated into C, I just want to know if there's a possibility to do that somehow, if there is, I believe it's gonna be a great improvement for any of the simulation environments. Thanks.

HY

Heilner

Also see this paper: dx.doi.org/10.3384/ecp12076443 – Cindiecindra

Answer 1

This is a good question and it comes up a lot. But first, let's step back for a second.

The idea of debugging "line by line" is something comes from imperative programming languages. By "imperative" I mean that a program is simply a sequence of instructions to be carried out in the specified order.

When someone debugs Java or Python, this "line by line" approach makes sense because the statements are the fundamental way behavior is represented. This "line by line" approach could also be extended to modeling formalisms like block diagrams (e.g. Simulink) because, while graphical, they are also imperative (i.e. they constitute steps to be carried out in a specified order).

But Modelica is not an imperative language. There is no notion of steps, statements or instructions. Instead, we have omnipresent equations. So thinking linearly about debugging doesn't work in Modelica. It is true that you could think about debugging the C code generated from Modelica, but that is typically not very useful because it bears only a partial resemblance to the equations.

So how do you debug Modelica code? Well, debugging Modelica code is really debugging Modelica equations. Normally, Modelica models are composed of components. The equations that are generated when components are connected are automatically generated so lets stipulate that the Modelica compiler generates those correctly. So what's left is the equations in the component models.

The simplest way to approach this is to test each component individually (or at least in the smallest possible models). I often say that trying to debug Modelica components by throwing them all together in a big model is like listening to an orchestra and trying to figure out the one instrument that is out of tune. The fact that these equations in Modelica tend to form simultaneous systems of equations means that errors, when they occur, can propagate immediately to a number of variables.

So your best bet is to go through and create tests for each individual component and verify the behavior of the component. My experience is that when you do this, you can track down and eliminate bugs pretty easily.

Update: You shouldn't need to add outputs to other people's component models to debug them. An output can be created at any level, e.g.

model SystemModel
  SomeoneElsesComponent a;
  SomeOtherGuysComponent b;
end SystemModel;

model SystemModel_Debug
  extends SystemModel;
  output Real someNestedSignalFromA = a.someSubsystem.someSubcomponent.someSignal;
  output Real someOtherNestedSignalFromB = b.anotherSubsystem.anotherSignal;
end SystemModel_Debug;

Of course, this becomes impractical if you have multiple instantiations of a signal component. In those cases, I admit that it is easier to modify the underlying model. But if they make their models replaceable, you can use the same trick as above (extends their model, add a bunch of custom outputs and then redeclare your model in place of the original).

Loya

Thanks a lot Micheal, I learnt a lot from your replies, and that's actually the reason I come to this place and post my questions. I agree with you that making each individual component (down to the lowest level) work properly is the best way, the thing is most of the time I work on the top level, and the low level codes are mostly from someone else. Large amount of my "debugging" time were spent into understanding others' code. So I really hoped if one day I could "see" how the variables change by debugging. Now what I did was just to duplicate their model and add an extra output to it. – Heilner

It works, but it just takes quite a lot of time modifying the original code. – Heilner

Keep in mind...you shouldn't need to add outputs to other people's models. See my update above. – Loya

Thank you so much Micheal, this is much cleverer than modifying others code. I started using Dymola a month ago, and there's so much to learn. Thanks for your help! I am quite looking forward to your new book btw. – Heilner

Suppose you have two subsystems, each of them has 10 nonlinear equations which are necessary for describing the behaviors, but when connecting them together, there would be an initialization failure caused by nonlinearity. In the above situation, how should I know exactly which equation causes the divergence? – Manumission

Answer 2

There is a transformation debugger in OpenModelica now. You can find here which variable is evaluated from which equation.

Saxon

Jan, what is the most updated documentation on the transformation debugger ? Thanks – Charles