State-machines translation error

[Andrea Bartolini]

Please consider the following state-machines basic-model:

model TwoStatesMachine1
  inner Integer i(start=0);

  block State1
    outer output Integer i;
  equation
    i = previous(i)+2;
  end State1;
  State1 state1;

  block State2
    outer output Integer i;
  equation
    i = previous(i)-1;
  end State2;
  State2 state2;

equation
    initialState(state1);
    transition(state1, state2, i>10, immediate=false, reset=true);
    transition(state2, state1, i<1, immediate=false, reset=true);

end TwoStatesMachine1;

Checking this model from OMEdit will produce the following error:

[1] 15:12:08 Translation Error
[StateMachines: 20:5-20:25]: Failed to elaborate expression: initialState(state1).

[2] 15:12:08 Translation Error
Error occurred while flattening model StateMachines.TwoStatesMachine1

if you comment-out the line "initialState(state1);" and retry to check the model, the following error is returned:

[1] 15:15:46 Translation Error
[StateMachines: 21:5-21:66]: Failed to elaborate expression: transition(state1, state2, i > 10, immediate = false, reset = true).

[2] 15:15:46 Translation Error
Error occurred while flattening model StateMachines.TwoStatesMachine1

Is there some flags or setting to be changed in order to activate the state-machines semantics in OMC?

OMEdit 1.13.0~dev-18-gf627d10
Connected to OpenModelica 1.13.0~dev-192-gd3b895d
SysOp: Linux Ubuntu 16.04 - 64 bit

[Bernhard Thiele]

Yes, try to give OMC the flag "+std=3.3" to enforce Modelica 3.3.
Otherwise, if the MSL is loaded first, OM probably switches to Modelica 3.2.

Following is an example of how Modelica 3.3 can be enforced by adding the flag in the simulation options dialog of OMEdit.

[Andrea Bartolini]

Thanks for quick reply,

I put the flag +std=3.3 in the OMEdit options, and now the check of the model rises the following error:

[1] 17:38:40 Translation Error
Internal error Check of StateMachines.TwoStatesMachine1 failed with no error message

which is a little obscure for me...

[Bernhard Thiele]

Yes, checks for state machines are not (yet) supported. I should look into the checking code and add meaningful diagnostics. However, simulation should work.

[Andrea Bartolini]

I confirm, the simulation works properly.

The only unexpected behavior (for me) is the obtained value of "previous(i)".... see the attached plot.

[Martin Sjölund]

@bthiele - stop using +d=... and +std=...; use -d= and --std= before they get deprecated ;)

[Bernhard Thiele]

@sjoelund.se - ok, good to know.

The plot for previous(i) is wrong and really weird. This seems to be an issue with the standard C run-time. If I simulate the model using the Cpp run-time, it looks fine, see the attached files.

@sjoelund.se - If I try to use the Cpp run-time with the standard nightly-build for Linux, I get a build error. I need to use my self-compiled omc version to get Cpp support. Do we only have support for the C run-time in the nightly-builds?

[Martin Sjölund]

Replying to bthiele:

@sjoelund.se - If I try to use the Cpp run-time with the standard nightly-build for Linux, I get a build error. I need to use my self-compiled omc version to get Cpp support. Do we only have support for the C run-time in the nightly-builds?

Try: sudo apt install libomccpp

[Bernhard Thiele]

Ah, thanks. I needed to also do sudo apt install libomp-dev, otherwise there was a compilation error. Which is a bit strange, since the compilation error was complaining about a missing omp library and libomp5 is already in the package dependencies (I'm using Ubuntu 16.04).

[Bernhard Thiele]

As discussed above I added support for state machines in the checkModel(..) function (​https://github.com/OpenModelica/OMCompiler/pull/1916).

[Francesco Casella]

Replying to bthiele:

Yes, try to give OMC the flag "+std=3.3" to enforce Modelica 3.3.
Otherwise, if the MSL is loaded first, OM probably switches to Modelica 3.2.

@bthiele two questions:

• why isn't +std=3.3 switched on by default? Is it still buggy to the point of being considered experimental?
• although adding this flag is obvious in hindsight, it is absolutely not the average user; consider that Andrea is now quite seasoned at using OMC and OMEdit for professional work, so he's not representative of the average user. If there are good reasons not to make +std=3.3 default, please add an indication to set this flag if you want to use state machines in the ​documentation

[Francesco Casella]

Replying to sjoelund.se:

@bthiele - stop using +d=... and +std=...; use -d= and --std= before they get deprecated ;)

If we don't phase them out anytime soon with *errors*, people will go on using them forever :)

[Martin Sjölund]

Replying to casella:

@bthiele two questions:

• why isn't +std=3.3 switched on by default? Is it still buggy to the point of being considered experimental?
• although adding this flag is obvious in hindsight, it is absolutely not the average user; consider that Andrea is now quite seasoned at using OMC and OMEdit for professional work, so he's not representative of the average user. If there are good reasons not to make +std=3.3 default, please add an indication to set this flag if you want to use state machines in the ​documentation

--std=3.3 is enabled by default. Loading an MSL version of 3.2.x sets it to --std=3.2.

[Bernhard Thiele]

Replying to casella:

• why isn't +std=3.3 switched on by default? Is it still buggy to the point of being considered experimental?

If I remember correctly there are models named Clock in the MSL, which conflicts with the Clock type. Dymola handles this by first searching for classes named Clock and if it doesn't find one it assumes it is a predefined Clock type.

I will have look at the documentation and add a remark about it.

[Francesco Casella]

Replying to sjoelund.se:

• why isn't +std=3.3 switched on by default? Is it still buggy to the point of being considered experimental?

--std=3.3 is enabled by default. Loading an MSL version of 3.2.x sets it to --std=3.2.

OK, but there is no MSL 3.3.x, so as soon as you use the MSL, which is pretty likely, it will fall back to 3.2, so this default is probably not very meaningful.

[Bernhard Thiele]

Added a note about --std=3.3 in the documentation (​https://github.com/OpenModelica/OpenModelica-doc/pull/59).

I guess I can close this ticket now.