Simulation stability

[Federerer]

Hi, I've noticed that sometimes, when I change order of components in schematic, the simulation gets unstable, even though the circuit hasn't changed. I also remember that I've read on some forum thread (found it 👉 link), mentioning using some trial and error heuristics to achieve a stable solution. So I implemented a quick and dirty test inside Analyze() function 😃

public Analysis Analyze()
        {
            Analysis mna = new Analysis();
            mna.PushContext(null, Nodes);
            Shuffle(Components);
            foreach (Component c in Components)
                c.Analyze(mna);
            mna.PopContext();
            return mna;
        }

where Shuffle() shuffles an array in place. And the results are promising, some permutations gives much more stable results than others. For practical use, this should be done probably somewhere else... like during the solving process, and it would be good to store the permutation seed value of 'best' solution for future use 😄

[dsharlet]

Really interesting idea. My guess is that this is something that some form of pivoting should solve, but we can't do full pivoting because the system of equations is symbolic when we need the pivots. Shuffling just randomly causes it to use different pivots, which apparently helps in some cases :)

I think maybe the best chance of integrating this cleanly is to try to learn about the stability of the circuit from solving for the initial conditions:

LiveSPICE/Circuit/Simulation/TransientSolution.cs

Line 108 in 01ca65b

List<Arrow> part = i.Equations.Select(j => Equal.New(j, 0)).NSolve(i.Unknowns.Select(j => Arrow.New(j, 0)));

This solver is more robust than the one used during simulation, and it doesn't need to be as fast as possible for the real time simulation, so adding some logic to it could be OK. If we could get it to tell us if the circuit is unstable, we could shuffle the components and try again.

However, I think I already try to use information from the initial conditions to select pivots for the real time solver, so maybe that is already learning as much information as possible from the initial conditions.

Do you have an example of a circuit that benefits from this shuffling?

[Gambitpawn1]

LiveSpice, I just downloaded it, I'm an amateur pedal and guitar amp modder and the idea of putting in a schematic, modding it and test driving the circuit before even modding the pedal or amp is AWESOME thank you guys! Will anyone be making any in depth tutorials/how to videos? I am definitely going to be sharing this with people in pedal/amp/DAW Facebook groups that I'm in. Next question, Facebook community?

[Gambitpawn1]

LiveSPICE, I have a request. A simulation that will show you your tone/frequency response like what you see on a Tone Stack Calculator. Pretty Please and thank you.

[dsharlet]

I've just merged a change to master that implements the idea we were discussing on #177. It improves pivot selection, and seems to very consistently improve sim speed, and only rarely hurts solve time.

I think there's probably still a lot of room for improvement in pivot selection. Just looking at whether a pivot has many zero eliminations or not is pretty crude, we could do a lot more than that (but we can't afford to do much here, because this code will be executed very frequently during row reduction).

[Federerer]

Can you clarify what you mean by CPU heavy?

I should specify, that this is the case when using dynamic parameters, in 'normal' mode this works fine. I think that dynamic parameters need a special treatment when pivoting, but I'm not sure if it's possible to know beforehand how choosing one pivot over another will affect the expression size after the back substitution. Brute force trying every possible option might not be too smart.

[dsharlet]

I just pushed a fix for the bug you found. This is sort of good news, because most of the extra work counting zeros was unnecessary. So perhaps it will fix the CPU issues you see in your dynamic parameters branch.

[Federerer]

After testing this on many permutations, I've newer got a working solution. It seems like the largest pivots are also the ones that produces huge expressions. Just for test, I've changed the pivot function to select a pivot only based on the lowest amount of zeroes, and I've got some working solutions.
I think that we might want to apply a strategy pattern here. This would allow us to switch between different pivoting functions at the runtime and allow A/B testing various algorithms.

[dsharlet]

I just pushed a change that gives a small but consistent further improvement in improvement in sim speed. I think it's basically another attempt at the idea that had a bug you found last time in the pivot selection algorithm (dsharlet/ComputerAlgebra@e857913). The implementation is much simpler and basically cost-free this time. The optimist in me is hoping this will disproportionately help with dynamic parameters :)

I'm pretty sure there's a much bigger opportunity here. I've been staring at a bunch of the systems of equations and their solutions, and I keep seeing dumb stuff that should be simpler. I keep thinking the problem is pivot selection, but I'm starting to think that the problem is we need some limited form of back substitution (the full BackSubstitute seems like it will not work).