Well, larger working space eventually, obviously. Kinda same with the multiple select, the whole GUI handling is mostly build for testing rather than serious use.
Doing your own GUI editor for circuit components is a lot of work, and I think you've made a great start Mystran! I decided it was too much work for me since my circuit solver is only for me so I took the easy way out, I use LTSpice to generate a netlist, which I then parse and turn into a C++ class which I compile and run as a plugin. Some day I hope to allow this to all happen dynamically, but right now it is a re-compile and a re-load of the host to listen, which is only around 10 seconds so not too bad.
Well, the amount of diode junctions to solve grows pretty quick, especially if you use transistors in a ladder (each transistor is 2 non-linearities). Sadly the time to solve the thing also usually grows faster than linear as the complexity increases. But I intend to eventually have "budget" version for transistors (assume forward bias, save half the work) and some lumped components (say transistors pairs) for situations where you don't really need everything simulated at the full detail.
I've found that the time taken does increase in a roughly linear way, the systems are pretty sparse so although the linear algebra could be around O(n^2.4) to O(n^3) with the number of nodes usually this doesn't come into it, I've found that around 0-1 div and around 2-20 total add mul sub operations per node. The computational load tends to be on non-linear function evaluations, which scale linearly with the number of non-linear components. As an example I have 4 pole filter circuits with 20 nodes that solve quicker than cascading two 2 pole circuits with around 12 nodes each, (so that is 24 total nodes). If there was a ^2 thing going on then the situation would be roughly 20^2 = 400, vs 2*12^2 = 288, so the two * 2 pole should be quicker, but the 4 pole solves faster! It is purely down to the two * 2 pole circuit having more non-linear elements in total than the 4 pole circuit.
Also for the transistors I've found it useful to optionally include different parts of the model via the model definition. For example in my basic BJT model I have the following parameters:
Code: Select all
qmod1 npn is=50e-15 nf=1.0 nr=1.0 bf=206 br=4 vaf=80 var=68 rb=0.3 rc=1.2 re=0.01
If you leave out nr / nf then it only evaluates the forward / reverse exponential function, if you leave out bf / br then it sets the forward /reverse beta to be infinite and so on. So for a perfect forward biased transistor you would use:
and only one exp is evaluated.
Hmmh.. pretty tiny differences in input can sometimes throw some circuits into slightly different states. IIRC there is a bit of dither which might be enough to get you different phase for self-oscillation and such.
Yep I agree here, but not even just the dither will do this, when it comes to self oscillating type things then even a tiny difference in the input signal can cause one filter to start oscillating before the other and create a phase difference in the sine waves.