id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
4656	Small delays give badly wrong results	Francesco Casella	Willi Braun	"Detailed transmission lines models require the use of cascaded pure time delays. High-resolution models require a large number of very small cascaded delays. Unfortunately, in this situation the way OMC handles delays is totally unsatisfactory.

The following model demonstrates the problem:
{{{
model TestDelay
  parameter Integer N = 100;
  parameter Real Tau = 10;
  parameter Real dt = Tau/N;
  Real y[N+1](start = zeros(N+1));
  Real out = y[N+1];
  Real x(start = 0, fixed = true);
equation
  y[1] = if time < 1 then 0 else 1;
  for j in 2:N+1 loop
    y[j] = delay(y[j-1], dt);
  end for;
  der(x) = 1-x;
  
annotation(
    experiment(StartTime = 0, StopTime = 20,
               Tolerance = 1e-06, Interval = 0.02));
end TestDelay;
}}}

This model apparently works fine: the variable {{{out}}} follows {{{y[1]}}} with a delay of 10 seconds. The output interval in this case is 20 ms, and each individual delay is 100 ms, which is an exact multiple. If you change Interval so that each individual delay is not an exact multiple of the interval itself, e.g. 30 ms, the output is warped. If the Interval is more than the delay, e.g. 120 ms, the result is severely wrong. If noEquidistantTimeGrid is activated, the result is even worse, apparently because of the large size of many steps (i.e, intervals in this case) compared to the individual time delays.

Dymola provides the correct results in all these cases.

In general, the correctness of the final state of a simulation should not depend on the communication interval length, at least if variable step-size solvers are used for the continuous-time part. In particular, it seems weird that to ensure the correctness of the delay() operator output, it is necessary to have a communication interval which is much shorter than the delay itself.

Can you please fix the implementation of the delay operator so as to avoid this syndrome?
"	defect	new	critical		Run-time				Lennart Ochel Patrick Täuber