clocked equations problem

[Niklas Worschech]

For the following model from the cpp runtime tests suite, it appears a wrong clock equation is generated.

model SolverMethod "Continuous PI controller in a clocked partition;
  see Modelica 3.3 spec, section 16.8.3 Associating a Solver to a Partition"
  parameter Real Ti = 200/1000, k = 2;
  parameter Real ref = 1;
  Real x(start = 0, fixed = true);
  Real xd(start = 0);
  Real vd, e, u;
equation
  // controller
  vd = sample(x, Clock(Clock(50,1000), solverMethod = "ImplicitEuler"));
  e = ref-vd;
  der(xd) = e/Ti;
  u = k*(e + xd);
  // physical model
  0.2*der(x) = hold(u);
end SolverMethod;

For the variable xd this equation is generated:

xd = DIVISION(e, Ti) * interval() + previous(xd)

I think this equation is not correct, because xd starts with an incorrect value. It starts with 0.25 but it should start with 0

[Rüdiger Franke]

See ModelicaSpec33, section 16.4 Discrete States: "The previous value of a clocked variable can be accessed with the previous operator. Such a variable is called a clocked state variable."

previous(xd) starts at 0

[Bernhard Thiele]

xd=0 at time=0 in Dymola. This is a clocked discretized continuous-time partition and for continuous-time variables the attribute start means the value at time=0. So xd should be zero at time=0.

[Rüdiger Franke]

Are you sure? Where does your statement find in the Modelica spec?

See the following continuous-time example:

model SIC
  Real x(start = 0, fixed = true);
equation
  der(x) = 1;
end SIC;

x starts with 0.

Now see the obvious discrete-time version of it:

model SID
  Real x(start = 0);
equation
  when Clock(0.1) then
    x = previous(x) + interval()*1;
  end when;
end SIC;

x starts at 0.1, despite of (start = 0).

[Bernhard Thiele]

At the end of MLS 16.8.2, p. 205, it says "The initial conditions will be used at the first tick of the clock, and the first integration step will go from the first to the second tick of the clock."

I think this sentence defines it, though it maybe could be made clearer.

[Rüdiger Franke]

I'd love to see this as a general rule for clocked equations, not just as a special rule if the clocked state comes from inline integration. A naive modeler would expect the model SID in comment:4 to start with 0 as well.

Alternatively, if both treatments of initial values are needed, then make a general rule for the case the start value is fixed or an initial equation exits (like for states coming from inline integration). I.e. in order to force the start value at the first clock tick:

model SID
  Real x(start = 0, fixed = true);
equation
  when Clock(0.1) then
    x = previous(x) + interval()*1;
  end when;
end SID;

[Rüdiger Franke]

I was wondering where comment:5 finds in ModelicaSpec 3.3, until I found out that it was only introduced in Revision1.

cde23af/OMCompiler keeps initial values of discretized continuous states at the first clock tick. I wished this was also supported for discrete states (see SID example above).

The implementation in SynchronousFeatures.mo might need to be improved. So far it is checked for a SolverMethod in the clocked partition. One might need to check each individual clocked variable instead -- e.g. communicate the info from solveContinuousEquations to the subsequent makePreviousFixed, or possibly combine these two functions into one, in order to look for der and previous with one traversal.

[Rüdiger Franke]

8987eb249/OMCompiler finally fixes the treatment of start values at the first clock tick. Each variable is treated individually now.

Beyond for clocked continuous states, the first value is hold for any clocked state with the attribute fixed=true. This solves the contradiction discussed in comment:4 above. I'll prepare a MCP to hopefully get this clarified in the Modelica spec.