The free response under zero coupling input, supplied when the modeled initial conditions require it. Runtime exposes this as ir; without a supplied IR sequence, the term is zero.
Technology
Compute the response.
Reuse the dynamics.
A linear time-invariant subsystem can be represented at its interface by response data. TDSE prepares that representation once and evaluates its contribution inside the host simulation loop.
01 / Why TDSE is fast
Prepare once.
Evaluate at every step.
TDSE turns a reusable linear subsystem into a prepared response operator. At each timestep, the host evaluates its interface contribution instead of reopening the subsystem’s internal equations.
Reuse / Less work to repeat
Traditional Approach
t0
Solve
t1
Solve
t2
Solve
t3
Solve
System solve at each step
Cost depends on sparsity and reuse of matrix factorization.
vs
TDSE Operator
offline
Build once
t0
Evaluate
t1
Evaluate
t2
Evaluate
Reusable operator
Dense history evaluation: O(P²·L), before host coupling costs.
One sequence · schematic, not measured timing
What changes—and what the host still owns
Change what gets reused at runtime.
Evaluate the subsystem’s interface contribution without reopening its internal equations. The host still solves the remaining coupling.
A schematic of where work happens, not a timing chart. The host still owns its coupled solve; an existing solver may already reuse its matrix factorization.
A conventional simulation solves the coupled system as time advances. TDSE moves the reusable LTI subsystem into a prepared response operator: build once, then evaluate its interface contribution at each step.
Conventional host loop
The reusable region participates in the system solve. Actual cost depends on model size, sparsity, factorization reuse and the integration method.
Cost depends on sparsity and reuse of matrix factorization.
TDSE-enabled host loop
The prepared region contributes interface terms without reopening its internal equations. The host solves the remaining coupling and commits the accepted state.
Dense history evaluation: O(P²·L), before host coupling costs.
Parallelism / Work side by side
Within each step,
work side by side.
TDSE organizes history-response evaluation as matrix–vector multiplication. Independent output rows can be computed side by side—a natural fit for parallel execution.
Time moves forward.
The work spreads out.
Inside one timestepGEMV
One shared history. Independent output rows.
Rows of the response matrix act on the same history vector, side by side.Inside the parallel evaluation
GEMV multiplies the prepared response matrix by the input-history vector to produce the history contribution. The CPU BLAS path delegates this operation to its math provider; thread configuration belongs to the host. Parallel work happens within a timestep, not across dependent future timesteps.
The host still solves the remaining coupling. Conventional solvers can also use parallel algorithms and reuse factorizations; TDSE changes the computational structure of the selected subsystem. Actual benefit depends on matrix shape, history length, memory bandwidth and execution overhead. The illustration shows the structure, not measured timing.
02 / Why TDSE is accurate
Keep the character.
Carry the response.
TDSE works directly with frequency-response data, without requiring an intermediate rational fit or step-by-step integration of the represented linear subsystem.
Preserve the model
Frequency dependence,
native.
Resonance, loss and delay already live in the frequency response. TDSE carries that information into a time-domain kernel—without first fitting a separate rational model.
For frequency-dependent transmission lines and other LTI models, that is one less approximation between the source data and the simulation.
Frequency response
IFFT
Time-domain kernel
No intermediate rational fit.
Illustrative analytic response pair. Frequency preparation precedes IFFT.Avoid an extra integration layer
Let the dynamics
keep their shape.
A numerical integration rule can shift a resonance or add damping. Change the rule in the illustration to see how the same model responds.
TDSE evaluates the prepared response kernel instead of applying those rules to the linear subsystem’s internal states. The host still owns its remaining dynamics and coupling.
The resonance shifts.
The same system. The same frequency axis. A different integration rule.Analytic example, not a TDSE benchmark · ζ = 0.075 · 8 samples per natural period. A coarse step makes the effect visible.
Model, formulas and preparation boundaries
Both illustrations use an analytic second-order oscillator with natural frequency ωn = 1 rad/s and damping ratio ζ = 0.075. The first is a schematic of the frequency-to-kernel route, using the continuous analytic transform pair, not an SDK-generated pack.
G(s) = 1 / (s² + 2ζs + 1)Trapezoidal: s = (2/Δt) · (z − 1)/(z + 1)Backward Euler: s = (1 − z⁻¹)/Δtz = exp(jωΔt); Δt = 2π/8, or 2π/32 with the finer step.The comparison evaluates these formulas at the same physical frequencies and on a fixed gain scale. Trapezoidal uses no prewarping. Smaller steps reduce these errors; the plot is not a claim about every solver or a measured TDSE advantage.
Direct frequency-response preparation avoids a mandatory rational fit, not all approximation. Finite bandwidth, frequency sampling, input-hold conventions, kernel truncation or compression and floating-point arithmetic still matter. Other methods can also use convolution or exact discretization.
Complete all frequency processing and establish the final grid before causality correction. Pass the corrected values, bins and endpoints unchanged to SDK IFFT / kernel construction. Changing the grid requires restarting from raw data.
Bilinear-transform reference · Integration-rule definitions · Builder data contracts
03 / The method
From a subsystem to a runtime operator.
Partition
Reusable LTIHost remainderBuilder
Time or frequencyRuntime Pack
Host Solver Loop
RuntimeTrial · solve · commitophrir
The response plots show alternative input routes: validated time-domain H data, with optional IR, or frequency-domain data converted into H. They are not two mandatory inputs. Builder writes the prepared representation as a Runtime Pack.
Partition
Define
Select an LTI region and explicit interface variables. Keep nonlinear and time-varying behavior in the host.
Builder → Runtime Pack
Prepare
Characterize the response, validate its grid and conventions, and build a Runtime pack.
Host Solver Loop
Evaluate
Query instantaneous, retained-history and independent-response terms; solve and commit in the host.
Read the derivation and modeling assumptions · Step-execution contract
04 / The equivalent equation
Three terms. One host-owned solve.
The subsystem response separates into an independent response, a retained-history contribution and an instantaneous coupling term. The host assembles these terms into its own governing equation.
Hover or focus to trace a term. Click or tap to pin; Esc to clear.
x[n] =++
Convolution over retained port history from previously committed steps. Runtime exposes this as hr; a rejected trial does not advance that history.
The current-step contribution coupled to the host’s trial state. Runtime supplies the instantaneous operator op; the host supplies the trial port input and solves for consistency.
From the equation to the SDK
y_trial = op * primary_trial + hr + ir
Notation and step conventions
In the schematic above, x[n] denotes the subsystem response, y denotes the coupled variables, and p(y) maps them to the subsystem’s coupling input. These are mathematical placeholders, not SDK variable names: the SDK calls its returned response y_trial and its trial input primary_trial. The prepared response h supplies the history and current-step contributions.
The schematic uses a fixed grid and sums retained committed history. Variable-step and input-hold conventions follow the theory and step-execution contract.
05 / The scaling law
Interfaces and history set the runtime work.
For a dense, square P-port response, retained-history evaluation scales as O(P² · L). The prepared subsystem’s full internal state count is no longer the dimension of this per-step convolution.
Hover or focus to trace a term. Click or tap to pin; Esc to clear.
O(·)
P is the port count in a square model. Each retained delay couples P inputs to P outputs. A carefully chosen boundary can keep this dimension small even when the subsystem interior is large.
L is the effective response-history length. Longer retained history increases convolution work and storage. Choose it against the required accuracy and response tail, not performance alone.
Keep the interface small. Retain the history the accuracy requires.
The rectangular form is O(Nq · Np · L), with Np input ports and Nq output equations. This describes the dense history kernel, not total simulator cost: host coupling, memory traffic, scheduling, backend and preparation amortization still matter. Compare with measured runtime results.
06 / Cost and conditions
Reuse is valuable when the boundary is right.
| Question | What to establish |
|---|---|
| Can the subsystem stay fixed? | Internal changes can invalidate prepared response data. Frequent rebuilds reduce the value of reuse. |
| How large is the interface? | Dense history evaluation scales approximately as O(P²L), with P ports and L retained history samples. Memory traffic and backend implementation still matter. |
| What is the comparison? | A conventional solver may reuse its matrix factorization. Compare against its actual sparse solve and reuse strategy—not an assumed new cubic-cost factorization every step. |
| Can preparation be amortized? | Measure model preparation, storage, repeated-run count and total simulation time, not just a prepared kernel step. |
| Does the host remain accurate? | Validate input hold, history, initialization, timestep changes, event windows and trial/commit sequencing against a declared reference. |
The cost expression describes the reusable subsystem contribution, not the complete simulator. Inspect measured timing and its scope.
07 / Numerical preparation
Causality is a preparation contract.
A reusable operator begins with a well-defined response. For frequency-domain inputs, the order of preparation is part of that definition—not an interchangeable set of cleanup operations.
- 01 Finalize processing and the frequency grid
- 02 Apply causality correction
- 03 Pass unchanged to SDK IFFT / kernel construction
For frequency-domain inputs, complete cropping, interpolation, resampling, extrapolation, filtering and the final frequency grid before causality correction. Correction is the final frequency-domain preparation step.
Pass the corrected values, bins and endpoints unchanged into SDK IFFT / kernel construction. A changed grid requires returning to raw data and correcting again. Read-only analysis must not feed modified spectra into simulation.
A method should be judged in context.
Review the public frequency, timestep, multiport and fault comparisons—including their non-advantage regimes.