Is delayTime approaching zero really that problematic?

[henrikt-ma]

The specification non-normatively explains:

Furthermore, the maximum step size of the integrator is limited by this minimum delay time in order to avoid extrapolation in the delay buffer.

My interpretation is that the following model is expected to get stuck at time π/2:

model DelayTimeApproachingZero
  Real x = time;
  Real w(unit = "rad/s") = 1.0;
  Real delayTime(unit = "s") = cos(w * time)^4 + Modelica.Constants.small;
  Real pastTime = time - delayTime;
  Real y = delay(x, delayTime, 2.0);
  annotation(experiment(StopTime = 6.3));
end DelayTimeApproachingZero;

But would it really be so bad to make it through periods of very small delayTime by doing a tiny bit of extrapolation between the most recent accepted step and the current intermediate step of the integration method?

I would be interested in hearing how different tools deal with the model above.

[henrikt-ma]

When thinking more about the expected structural change at zero delayTime, I realize that interpolation using the current intermediate step value of the delayed expression wasn't a very good idea. It would make more sense to me to perform extrapolation using only points recorded at already accepted steps. Still, I imagine that this could be a feasible way of making it through passages with delayTime near zero.

What this would really mean for the numeric quality of the completed solution I don't know, but if it turns out that several tools already apply similar strategies for coping with near zero delayTime we should probably remove the non-normative sentence about delayTime imposing an upper bound on the integrator step size.

[HansOlsson]

My concern would be the stability of delay differential equations (the example above doesn't have any differential equations), which is messy in general and I can only assume that it becomes worse when the delay approaches zero.

Since we also have differential algebraic systems there's also the possibility of delay algebraic systems with delay going to zero that is just a mess - e.g.,:

Real z = x+(1-1e-6)*delay(z, delayTime, 2.0);

Using extrapolation for those cases is clearly complicated.

[HansOlsson]

Language group: Short fixed delays seems most liked used for breaking algebraic loops. With interpolation that may work even with short time intervals (for implicit one-leg solvers; implicit high order Runge-Kutta methods are more complicated).

May make the text is less strict. (So it can be handled, but not the best of ideas.)

[henrikt-ma]

Sorry, I was a bit confused during the meeting. I actually don't see a problem at all with the interpolation for BDF methods – am I missing something? If not, I think this shows clearly that the current non-normative statement is too strong.

Edit: Double sorry, I now recall where the confusion was coming from. We have discussed so much in the direction of establishing delay as a decoupling operator, but you can't have your cake and eat it too. If delay should be a decoupling operator, also a BDF method will need to extrapolate since the decoupling requires that the output value of the delay call can be computed without yet knowing the current value of the input.

Hence, I take back my statement that the current non-normative statement clearly is too strong. Instead, if we really care about the decoupling power of delay, I think we should move the statement out of the non-normative section, and say something like the following:

Using a delay time too close to zero may compromise correctness due to the need for delay buffer extrapolation. It is a quality of implementation to make the tradeoff between integration step size and delay operator correctness.

[HansOlsson]

Sorry, I was a bit confused during the meeting. I actually don't see a problem at all with the interpolation for BDF methods – am I missing something? If not, I think this shows clearly that the current non-normative statement is too strong.

My main concern was for Fully Implicit Runge-Kutta methods like Radau, where you suddenly get a new form of direct dependency between the stages.

Using a delay time too close to zero may compromise correctness due to the need for delay buffer extrapolation. It is a quality of implementation to make the tradeoff between integration step size and delay operator correctness.

Ok, that would work.