Why applying an integration algorithm to whole DAEs?

Let me ask a fundamental question which may be trivial to experts in this field.

Compared with solving a set of ODEs, solving a set of DAEs is much more difficult. For instance, in the case of electrical circuits, the equations to be solved are in general DAEs. So, if you try to solve the circuit equations in a straightforward way, you have to apply a highly sophisticated integration algorithm, such as RADAU5, which has been created as a result of extensive research results. But, this is because you apply an integration algorithm to the whole DAEs. However, practical simulation programs such as SPICE, EMTP and etc apply a simple integration algorithm to individual dynamic components, i.e. inductors and capacitors to obtain a set of algebraic equations to be solved at each time step. And, this simple method works just fine.

So, what is the drawback to apply an integration algorithm to each dynamic component, instead of applying it to the whole DAEs? So far, I don’t see any drawback and wonder why such highly sophisticated integration algorithms are being studied.

2 Likes

Not handling the full coupling is only an approximate solution. Sometimes it’s unstable, and sometimes the approximation isn’t justified to fully converge. There are some examples of this in the Causal.jl documentation: Algebraic Loops · Causal.

3 Likes

Noda-san has a remarkable professional and academic record on the subject of electrical circuit simulation and his question are well rooted when it come to real-world circuit simulation.

Causal.jl seems to involve stitching together “causal” subsystems without true (extra implicit equation) tight couplings between them. This modeling/simulation approach resembles what I understand Modelica does, and it is right to assume that things will break rather quickly if you use it to try to solve tightly coupled non-linear circuits. The tell-tale sign is the actual mention of Algebraic loop breaking.

Getting right to the point: the (otherwise awesome) DiffEq environment seems to be rooted on the fact that external integration of the function using a common scheme will work for every situation.

I don’t have the academic background to prove that it is wrong in our domain, but I can tell by experience that no commercial analog circuit simulation solution uses external integration.
The convergence/accuracy issues in “analog” circuit simulators (SPICE-class) don’t come from integration (Backward-Euler / Trapezoidal / GEAR are used) when you can handle discontinuities at the equation/block level.

He was maybe thinking about a new type of DE system, let’s say “SPICEsystem” with specific implicit integration scheme that would allow each independent equation to handle integration and discontinuities. He maybe understood, like I did, that existing Julia DE systems could only use explicit integration algorithms, and this looks like a requirement.

For me, it is a limitation.

It might break the ecosystem, but I kindly suggest you should consider be more open on other proven simulation engines architectures.

This said, I can’t thank you enough for the DiffEq ecosystem, ModelingToolKit.jl being for me the de-facto symbolic framework to use.

Modelica does not do this. Modelica does acausal modeling. You can transform acausal models to DAEs through index reduction, get large algebraic loops, and decouple the nonlinear solves, but the system is still fully coupled.

It does not.

What? There’s more than a few implicit methods here: https://diffeq.sciml.ai/stable/solvers/ode_solve/. I don’t know where you’re getting your information…

Like what? Modelica for example is a subset of MTK, so it would strictly decrease the capabilities to restrict to it.