Modelica unexpected behaviour of assertion

openmodelica
modelica by example
modelica by example pdf
openmodelica user guide
modelica text editor
modelica tool
modelica manual
openmodelica tutorial

I need to assert that a variable (a in the MWE below) is bigger than another (b).

I noticed that an assertion a>b inside an imported model behaved like a>=b. I tried to work around that problem to assert for a>(b+Constants.small) instead. Changing the assertion, even when asserting for a>(b+someBiggerNumber) still doesn' works as expected for a=b. If a!=b the assertion works as expected.

Is this a bug or am I doing something wrong? If it"s a bug, is there a workaround?

MWE:

model MWE

  model SomeModel
    parameter Real a(start=1);
    parameter Real b(start=1);
  protected
    Real c=5/(a-b);
  equation
    assert(a > b, "a has to be bigger than b. However, a (=" + String(a) +") < b (=" + String(b) + ")");
    //assert(a > (b + 1), "a has to be bigger than b+1. However, a (=" + String(a) +") < b (=" + String(b) + ")");
  end SomeModel;

  SomeModel sm(a = 5, b = 5);
  Real var;

equation
  var = sm.c;

end MWE;

// assert a > b
// a=5, b=4 no fail, as expected, same for b<4
// a=5, b=5 no fail
// a=5, b=6 fail, as expected, same for b>3

// assert a > (b + 1)
// a=5, b=3 no fail, as expected, same for b<3
// a=5, b=4 fail, as expected
// a=5, b=5 no fail
// a=5, b=6 fail, as expected, same for b>3

If you want to get a predictable order, use one algorithm:

  protected
    Real c;
algorithm
    assert(a > b, "a has to be bigger than b. However, a (=" + String(a) +") <= b (=" + String(b) + ")");
    c:=5/(a-b);

Alternatively turn this into a function and have the assert inside the function.

ModelicaReference.Operators.'assert()', assert()'. Information. Trigger error and print error message if assertion condition is not fulfilled statement shall have no influence on the behavior of the model. Modelica by Example. It is important to note that when an if statement appears in an equation section, the number of equations must be the same regardless of which branch through the if statement is taken (this applies in the presence of elseif as well).

You can check Real variables for equality with Modelica.Math.isEqual(a,b) and combine it like this: (a > b) or Modelica.Math.isEqual(a,b)

3074 (Insufficient information about assertion , According to the non-normative text of the Modelica Specification, Section 8.3.7, you should get something like. The following assertion has been violated at time � Using the MSL 3.2.1 CombiTimeTable applying the parameter startTime != 0 leads to a unexpected behaviour: The table output is not only shifted in time but shows a somehow morphed and discuntiuous, stepped behaviour.

As usual the problem is sitting in front of the keyboard :/

I couldn't wrap my head around the problem by stepping through it in my head. The assertion works fine, but Modelica doesn't step through the equations sequentially like most programming languages do and therefore runs into a division by zero error before asserting anything.

Changing the sequence like this

  protected
    Real c;
  initial equation
    assert(a > b, "a has to be bigger than b. However, a (=" + String(a) +") < b (=" + String(b) + ")");
  algorithm
    assert(a > b, "a has to be bigger than b. However, a (=" + String(a) +") < b (=" + String(b) + ")");
  equation
    assert(a > b, "a has to be bigger than b. However, a (=" + String(a) +") < b (=" + String(b) + ")");
    c=5/(a-b);

doesn't change that.

If anyone knows how to run the assertion first to get cleaner error messages your input woud be welcome :)

[PDF] Modelica, statement shall have no influence on the behavior of the model. This can lead to surprising behavior, because the actions of a state are� Modelica by Example. Events¶. In the first chapter on Basic Equations we saw examples of how to describe continuous behavior. The equations introduced in that chapter applied at all times and the solutions to those equations were always continuous.

you have to do the part you want to have control over in the algorithm section such as:

model MWE

  model SomeModel
    parameter Real a(start=1);
    parameter Real b(start=1);
  protected
    Real c;
  algorithm
      assert(a > b, "a has to be bigger than b. However, a (=" + String(a) +") < b (=" + String(b) + ")");
    //assert(a > (b + 1), "a has to be bigger than b+1. However, a (=" + String(a) +") < b (=" + String(b) + ")");
    c := 5/(a-b);
  end SomeModel;

  SomeModel sm(a = 5, b = 5);
  Real var;

equation
  var = sm.c;

end MWE;

If you put two assignments in an algorithm, they will for sure be executed in that exact order. The compiler is free to change order of other equations though and if i am not incorrect asserts are treated as "removed equations" which do not have any output value contributing to the simulation, those are computed after a full step. So it will always be after the equation got evaluated. It is done this way because asserts are usually tested at the end of a step to prevent the next one from happening.

EDIT: ah i just saw that @Hans Olson posted the same solution, sorry!

Introduction to Modeling and Simulation of Technical and Physical , reproduced in this book with permission from the Modelica Association under the Modelica License 2. Copyright Mental model—a statement like “a person is reliable” helps us A simulation of vehicle behavior, for example, of a car or an airplane, for the FlatTank model, which is not surprising given that both models. Expressions¶. Most of the time, the expression expr is going to be a conditional expression and usually it will involve relational operators. Typical examples of expressions frequently used with a when statement would be time>=2.0, x>=y+2, phi<=prev_phi and so on.

[PDF] Types in the Modelica Language, for describing Modelica types is given as a starting patible compilers and unexpected behavior when Robin Milner's famous statement ”Well-typed pro-. patible compilers and unexpected behavior when using the language. The purpose of this paper is twofold. The flrst part gives an overview of the concept of types, states concrete deflnitions, and explains how this relates to the Modelica language. Hence, the flrst goal is to augment the computer science perspec-

Newest 'openmodelica' Questions, OpenModelica is an open-source Modelica-based modeling and simulation environment. 1. 1 Modelica unexpected behaviour of assertion � assertion� Though being unexpected probably, it actually is by design that CombiTable1D, CombiTable1Ds and CombiTable2D always extrapolate linearly no matter how the interpolation is set. Block ModelicaTest.Tables.CombiTable2D.Test19.combiTable1D is a test example for it. In #1313 I also raised this topic (under wrong assumptions) but nobody replied.

Modeling System Requirements in Modelica, Assertions, Modelica, Safety, Verification, Validation. 1. Introduction in an equation-based context, the behavior of each system component, as well consequently propagation of possible unexpected values in a component� dynamic state of the system can evolve in time (the term “behavior” refers to “state-based behavior” in the remainder of this paper). The development of the behavior ontology was motivated by the difficulty of maintaining a consistent behavior specification within the existing systems engineering process.

Comments
  • I get the same results with this. Asserting in the model MWE works fine (your solution as well), the problem only occurs when I try to assert inside of an imported model.