Opened 4 years ago

Closed 3 years ago

#6132 closed defect (fixed)

backenddaeinfo states wrong number if discrete states

Reported by: rfranke Owned by: Karim.Abdelhak
Priority: high Milestone: 1.16.0
Component: Backend Version: v1.16.0-dev
Keywords: Cc:

Description

Consider the following model with one discrete state x:

model DiscreteState
  input Real u(start = 1);
  Real x(start = 0);
equation
  when Clock(0.1) then
    der(x) = u;
  end when;
end DiscreteState;

Compilation with -d=backenddaeinfo states 0 discrete states:

Model statistics after passing the back-end for simulation:
 * Number of independent subsystems: 1
 * Number of states: 0 ()
 * Number of discrete variables: 0 ()
 * Number of discrete states: 0 ()
 * Top-level inputs: 0

Change History (10)

comment:1 Changed 4 years ago by Karim.Abdelhak

Well that is not how a discrete state is defined... A discrete state is a discrete variable of which the left limit value during events influences the current states. So a discrete variable which appears inside a pre() operator (or other operators that imply this).

A quick example:

model DiscreteState2
  Real x(start=1.0);
algorithm
  when sample(0.0, 1.0) then
     x := x + pre(x);
  end when;
end DiscreteState2;

Compiled with -d=backenddaeinfo,discreteinfo it yields:

Notification: Model statistics after passing the back-end for simulation:
 * Number of independent subsystems: 1
 * Number of states: 0 ('-d=stateselection' for list of states)
 * Number of discrete variables: 2 ($whenCondition1,x)
 * Number of discrete states: 2 (x,$whenCondition1)
 * Top-level inputs: 0

The sample-operator also implies a discrete state. Discrete states are also always just discrete variables.

Does this answer your question or is there another intent behind this?

Last edited 4 years ago by Karim.Abdelhak (previous) (diff)

comment:2 follow-up: Changed 4 years ago by Karim.Abdelhak

Okay i looked a bit closer and i now understand that your model also implies the pre() operator. Sorry for the misunderstanding!

I ran your model and i do not really get the outcome. But if the outcome is correct i could just try to add this case to be counted as a discrete state. Or is the simulation also incorrect?

Last edited 4 years ago by Karim.Abdelhak (previous) (diff)

comment:3 in reply to: ↑ 2 Changed 4 years ago by casella

Replying to Karim.Abdelhak:

Okay i looked a bit closer and i now understand that your model also implies the pre() operator. Sorry for the misunderstanding!

I'm sorry but I couldn't follow you here. I understand the model DiscreteState has one clocked discretized continuous-time partition, which contains a differential equation. If I understand correctly Section 16.8 of the specification, this equation will be discretized by some method, and the discretized version of it will use previous(x), not pre(x). Variable x will not be a discrete variable (which is defined for all values of times and only changes at events), but rather a clocked variable, which is only defined at clock instants.

Do clocked variables with previous(x) belong to the set of discrete states?

BTW, should Appendix C of the Modelica Specification be updated to include clocked variables?

comment:4 Changed 4 years ago by rfranke

Sorry for having messed up the example with a continuous-time state in a clocked partition. This model generates one continuous-time state:

model ContinuousState
  input Real u(start = 1);
  Real x(start = 0);
equation
  //when Clock(0.1) then
    der(x) = u;
  //end when;
end ContinuousState;

Including when Clock this becomes one discrete-time state (e.g. automatically converted to x=previous(x)+u*interval()). See 16.4 Discrete States.

Why does the current backenddaeinfo distinguish between "discrete variables" and "discrete states" that appear to be the same in the example with pre above?

Could possibly "discrete states" refer to clocked states instead?
Alternatively a new line for clocked states?

comment:5 Changed 4 years ago by casella

I understand from the specification that the way discrete states and clocked states are handled are quite different, e.g. regarding the initialization.

I guess they should be listed separately.

comment:6 follow-up: Changed 4 years ago by rfranke

Do you have an example where current "discrete variables" and "discrete states" make a difference?

comment:7 in reply to: ↑ 6 Changed 3 years ago by Karim.Abdelhak

Replying to rfranke:

Do you have an example where current "discrete variables" and "discrete states" make a difference?

Take your model and add a variable Real i(start=1.0) and add the equation:

when time > 0.5 then
  i = x + 1;
end when;

Here i as well as the when-condition are discrete but not states.

I added reporting clocked states in PR6773, it now looks like this (using -d=backenddaeinfo,discreteinfo):

Notification: Model statistics after passing the back-end for simulation:
 * Number of independent subsystems: 1
 * Number of states: 0 ('-d=stateselection' for list of states)
 * Number of discrete variables: 2 ($whenCondition1,i)
 * Number of discrete states: 0 ()
 * Number of clocked states: 1 (x)
 * Top-level inputs: 0

I will probably have to fixup some part of the testsuite, but before i do that i would like a conformation that this is what you wanted. Seems good to me at least!

comment:8 follow-up: Changed 3 years ago by rfranke

Looks good!

I'm wondering though if OpenModelica should not reject the model DiscreteState extended with your when time > 0.5 clause. I'm assuming that it is not valid to mix clocked variables with discrete variables. The correct equation should be i = hold(x) + 1 imho!? Then i changes at time 0.5, whereas OMEdit changes it at time 0.6 in the presumably wrong model.

But that's not related to your extended notification.

comment:9 in reply to: ↑ 8 Changed 3 years ago by Karim.Abdelhak

Replying to rfranke:

Looks good!

I'm wondering though if OpenModelica should not reject the model DiscreteState extended with your when time > 0.5 clause. I'm assuming that it is not valid to mix clocked variables with discrete variables. The correct equation should be i = hold(x) + 1 imho!? Then i changes at time 0.5, whereas OMEdit changes it at time 0.6 in the presumably wrong model.

But that's not related to your extended notification.

Okay, but good that i brought it up i guess!

comment:10 Changed 3 years ago by Karim.Abdelhak

  • Resolution set to fixed
  • Status changed from new to closed

It is pushed, clocked states are now reported!

Note: See TracTickets for help on using tickets.