Code generation contains `Differential` when equations contain variable time parameter

[bradcarman]

Take the following

@component function FilteredInput(; name, x0=0, T=0.1)
    params = @parameters begin
      k(t) = x0
      T = T
    end
    vars = @variables begin
      x(t) = k
      dx(t) = 0
      ddx(t)
    end
    systems = []
    eqs = [
      D(x) ~ dx
      D(dx) ~ ddx
      dx ~ (k - x)/T
    ]
    return ODESystem(eqs, t, vars, params; systems, name)
end

@mtkbuild sys = FilteredInput()
ModelingToolkit.observed(sys)

gives...

julia> ModelingToolkit.observed(sys)
3-element Vector{Equation}:
 dx(t) ~ (k(t) - x(t)) / T
 dxˍt(t) ~ (-dx(t) + Differential(t)(k(t))) / T
 ddx(t) ~ dxˍt(t)

Note the Differential(t)(k(t))) which cannot be computed.

Manifest:

[961ee093] ModelingToolkit v9.66.0

[baggepinnen]

One problem here is that if k is a function of time, then the named variable ddx will depend on the time derivative of k, D(k), and there is no way for MTK to know what the derivative of this time-dependent parameter is. The problem goes away if you don't name ddx, and instead write the model as

julia> @component function FilteredInput(; name, x0=0, T=0.1)
           params = @parameters begin
             k(t) = x0
             T = T
           end
           vars = @variables begin
             x(t) = k
             dx(t) = 0
           end
           systems = []
           eqs = [
             D(x) ~ dx
             D(dx) ~ (k - x)/T
           ]
           return ODESystem(eqs, t, vars, params; systems, name)
       end

julia> @mtkbuild sys = FilteredInput()

julia> ModelingToolkit.observed(sys)
Equation[]

since then MTK has no reason to make ddx available as an observed, and the detivative of k never appears in any expression, it's only being integrated.

Furthermore, if you intend for k(t) to be piecewise constant, the derivative of k is infinite or ill defined at the time points when k changes.

[AayushSabharwal]

Making parameter derivatives zero should handle this?

[ChrisRackauckas]

We do need to make sure that when a parameter is a function, say a datainterpolation, that we still handle that case correctly.

[baggepinnen]

Making parameter derivatives zero should handle this?

"handle"... if the derivative is zero then there's no need to have the parameter depend on time. If the parameter truly does vary with time it's wrong to just assume that the derivative is zero.

[ChrisRackauckas]

Well the issue here is that discrete variables and parameter functions need to do this separately.

[baggepinnen]

In both cases is it wrong to assume that the derivative is zero. A discrete-time variable that is piecewise constant has an ill-defined derivative (in the non-distribution sense at least) at the time point when it changes value, if the model is such that it depends on this derivative, the model is probably wrong. If the parameter is a function of time and MTK knows the derivative of this function it is fine, otherwise erroring is the only reasonable option.

[hersle]

See also #2823 (from #2823 (comment) and below). A good solution to this issue would probably also solve that issue.

[AayushSabharwal]

We do need to handle parameter derivatives in the explicit case at least.

A discrete-time variable that is piecewise constant has an ill-defined derivative (in the non-distribution sense at least) at the time point when it changes value

Isn't that the point of it being discrete-time, though? The callback handles the instantaneous change in value, and the assumption of the derivative being zero holds at all other time points. Is there a case where it would give an incorrect result?

At the very least, I think we can allow explicitly specifying parameter derivatives and erroring when they're required but not provided.

[baggepinnen]

Is there a case where it would give an incorrect result?

It hides a likely model error, MTK is not supposed to have to differentiate such a discrete-time parameter. Take the model in the OP as an example, ddx contains the time derivative of k which is an impulse, this is not mechanically feasible and the k should have been added to the acceleration rather than the velocity, i.e., a model error. One cannot perturb a velocity other than through a force, and forces affect the acceleration, they only affect velocity through integration of the acceleration.

Change the domain from mechanical to electrical or any other and you get the same problem, MTK should error if you try to impulsively disturb a variable in any other way than to explicitly change the variable in a callback. Note, it's k being modified by the callback here, not ddx, which would be implicitly disturbed impulsively.

[AayushSabharwal]

Interesting. So time-dependent parameter derivatives should error unless the user explicitly provides a derivative for them?

[baggepinnen]

If the derivative is of a parameter that changes discretely, then yes, that's my opinion at least. In the FMU case, the output is probably a continuous variable with a well-defined time derivative, and it's our problem that we call that a parameter 😅

The modelica crowd has a number of recent papers on how to do the right thing with Dirac impulses, but I don't think any tool implements this research yet.

[AayushSabharwal]

In the FMU case, the output is probably a continuous variable with a well-defined time derivative, and it's our problem that we call that a parameter

Well yes and no. CoSimulation FMUs by nature are meant to be handled via callbacks, and their outputs/states are discrete variables. Discrete variables are stored in the parameter struct. If a model uses the output of such an FMU in an equation that MTK differentiates, then this is still valid. The FMU allows obtaining the output derivative, we just don't have a way to hook into it yet. The question then arises what to do if the FMU doesn't support calculating a high enough order derivative. Error?