refactor: reduce size of inline linear solves

[AayushSabharwal]

By manually tearing some simple equations in the linear SCC, we can greatly reduce the size of the SCC.

[oscardssmith]

this really feels like the wrong level to do this at. rather than making the big linear system and shrinking, why can't we identify the minimal necessary linear system to solve up front?

[AayushSabharwal]

By "up front" do you mean when building the A and b matrices in the same function? I'll think about it. Currently, the reason I did this separately is that we build A column-wise, but analyze individual rows to figure out which to remove.

[oscardssmith]

I mean that this feels like it really should be tearing's job to only put variables/equations into the SCC if doing so is a good idea.

[AayushSabharwal]

only put variables/equations into the SCC

I'm not sure what this statement means. Tearing doesn't "put" anything into SCCs. The SCCs arise from the equations, they exist before tearing ever does anything. The job of tearing is to process each SCC in turn, and try to find the best way to causalize it. This is exactly what it does. It is a graph algorithm, and has no notion of MTK.

For the SCCs we generate linsolves for, tearing cannot causalize them because there is a causal loop (hence the SCC) so it breaks the loop by marking some variables as algebraic, and solving the rest in terms of those algebraic variables. The inline linear SCC pass simply steps in, recognizes that the SCC is effectively one big linear solve and generates exactly that instead of algebraic equations. Now for a linear system, tearing simply reduces the size. It does not guarantee that the reduced system is well-conditioned, which is why until now we generated a linsolve for the entire thing. This PR aims at reducing the size of the linear system in a way that hopefully does not cause it to become ill-conditioned.

[oscardssmith]

fair enough. This then seems reasonable to me.