Modeling Time Delays (Stabilizer + Other)

[lukelowry]

Summary

GridKit does not have a way to model time-delayed, causal signals in PhasorDynamics, or in any other module, as far as I know. At any given time $t$, a model should receive or read the 'history' of an external state at $t-\tau$ via a signal (perhaps consider in signal redesign #354). I'm not sure whether this would cause issues with Enzyme or IDA.

Rationale

Models such as IEEEST have a parameter that sets the (causal) delay of the input $u_{d}(t)= u(t-\tau)$. Without a way to read historical external states, we cannot faithfully model some cases. This is a reletively common stabilizer model.

Additionally, more advanced EMT models require time delays for propagation.

Description

I am not sure how this would interfere with the solver, and I think that is where the tension will sit. Since the feature is for causal, historical states, perhaps there is a way to 'route' data back into a model through a signal port?

Additional information

No response

[alexander-novo]

I don't think IDA supports time-delay equations. (@Steven-Roberts)

It is possible to add it as a feature to the up-and-coming Rosenbrock integrator, though (or a future hypothetical RK integrator).

Is the time delay τ fixed/constant, or does it depend on the state/time?

[Steven-Roberts]

I don't think IDA supports time-delay equations.

That's correct

[lukelowry]

Is the time delay τ fixed/constant, or does it depend on the state/time?

Always fixed. It's a parameter of models like the stabilizer. Also, having fixed, delayed signal inputs would allow us to implement frequency-dependent transmission line models, which are generally considered the most accurate. Above a certain frequency threshold, time-delay signal inputs are required to model the transmission line accurately

If it's purely historical and the delay is much larger than the expected time steps, can't we just treat the historical signal as a forcing function? and read it from memory?

[alexander-novo]

delay is much larger than the expected time steps

Can you expand on this? Are you sure it will be much larger than the time steps taken by the integrator, or will it just be much larger than the interval of outputs? Asking because the integrator can and will take steps larger than the time between requested outputs.

and read it from memory?

This is a little problematic for IDA in particular. I've asked @Steven-Roberts about this before, and right now IDA only supports sampling the solution at arbitrary time points if those time are during the last step taken. If we need to sample from the solution from before the last time step (like you say in the previous part), there isn't really a way right now to store something in memory that would allow us to sample the forcing function.

Also I don't know how this would affect IDA in particular (@Steven-Roberts can definitely answer this), but DDEs tend to introduce discontinuities in the derivatives of the solution. Do you know for these particular models whether or not this would be the case?

[lukelowry]

Stabilizers in PhasorDynamics are commonly tuned to dampen low-frequency oscillation modes at ~0.7-2.0 Hz, whereas the requested output interval is typically a quarter cycle (~240 Hz), representing about a two-order-of-magnitude difference in time scale. That being said, there will undoubtedly be a model people use that samples more closely to the time scale of the requested simulation interval. Someone/thing will eventually abuse that feature if it exists

Sad news about the reading from memory. seems like a show stopper then

Interestingly, for the frequency-dependent TL models, the impulse response at one end of the transmission line i(t) disperses by the time it reaches the other bus $i(t-\tau)=(h*i)(t)$, tho there is still the causal delay. It's not infeasible to build a toy network model with long, lossy lines to minimize the relative magnitude of discontinuities for IDA.

[Steven-Roberts]

If it's purely historical and the delay is much larger than the expected time steps, can't we just treat the historical signal as a forcing function? and read it from memory?

In principle, yes.

This is a little problematic for IDA in particular. I've asked @Steven-Roberts about this before, and right now IDA only supports sampling the solution at arbitrary time points if those time are during the last step taken. If we need to sample from the solution from before the last time step (like you say in the previous part), there isn't really a way right now to store something in memory that would allow us to sample the forcing function.

That's correct.

Also I don't know how this would affect IDA in particular (@Steven-Roberts can definitely answer this), but DDEs tend to introduce discontinuities in the derivatives of the solution.

Yes, that could be problematic.

Supporting DDEs robustly would require significant changes to IDA that are probably out of scope for the current project. It may be possible to hack together a temporary solution which saves snapshots of past states in GridKit and uses interpolation to get the delayed state needed in the right-hand side function, but this seems quite fragile.

[lukelowry]

How about a single time step delay? If I want one state to always equal the value of another state at the previous time step, is this more possible?

I think at the start of our discussion you said that might be possible. Would that be difficult? I suppose it would be a GridKit level management where we keep the previous state before updating the next state.

Is this feasible?

[alexander-novo]

If we capped the time step taken by the integrator to the minimum delay needed in the simulation, then this can be easily added in the way you described to the Rosenbrock integrator. As well, we can store a history which can be sampled arbitrarily far back. The memory cost for high-order methods will be $(p - 1) * n$ state vectors, where $p$ is the order of integration ($p = 5$ is reasonable) and $n$ is the number of steps taken since the largest delay in the system.

The only problem I foresee is that $n$ can get quite large (~1e4 - ~1e5) after discrete events like faults.

Also this is just from the integrator's capability point of view. Gridkit would have to allow some way of sampling the history.

EDIT: We could also potentially reduce memory burden by only storing the specific variables we will be sampling the history of.