Switch-mode BJT transient simulation failed

[ra3xdh]

Transient simulation for some types of bipolar transistors (switch-mode) failed. 2N2222A works ok, but 2N3055 fails. This bug appears for some other types of BJTs and with some conditions for MOSFETs.

Schematic is here:

It is available also at Gist: https://gist.github.com/ra3xdh/6cd1996486c1c5e59e32/download Simulation log is here.

WARNING: TR1: inserted virtual resistance at node `_net0' connected to [R2,V1]
WARNING: TR1: inserted virtual resistance at node `_net2' connected to [_Rbb#Q2N3055_1,R2,R4]
WARNING: TR1: inserted virtual resistance at node `_base#Q2N3055_1' connected to [_Rbb#Q2N3055_1,Q2N3055_1]
WARNING: TR1: inserted virtual resistance at node `_net1' connected to [R5,V2]
WARNING: TR1: inserted virtual resistance at node `_collector#Q2N3055_1' connected to [_Rc#Q2N3055_1,Q2N3055_1]
ERROR: TR1: Jacobian singular at t = 1.000e-10, aborting transient analysis

[guitorri]

For some reason the system is becoming singular. The warnings are coming from here: https://github.com/Qucs/qucs/blob/master/qucs-core/src/nasolver.cpp#L184

[broucaries]

Using eigen advanced solver will help here.

[in3otd]

it seems that there are several issues here:

• the rectangular voltage source has a problem (as I was mentioning on Qucs-help): its DC value is strangely defined as its mean value (i.e. will be 2.5 V for a square wave source with 5 V amplitude). The transient simulation uses the DC value as the value for t=0 (seems reasonable...) but in this case this will cause a discontinuity, since the source value for the next point (t>0) will be zero, no matter how small the timestep is.
• BJT which have the excess phase parameter specified (PTF>0) will cause the NR iterations to loop indefinitely or to fail to converge. I am checking the BJT model code and while it seems to have some slight differences w.r.t. the SPICE code I did not find any obvious error up to now.
• last and least important, the usual problem with PWL sources which cause some extra work for qucsatorto go over the switching points

[AndreaLu]

I wanted to report another switching circuit where transient simulation generates a singular jacobian (cockroft-walton voltage multiplier): simlog.txt netlist.txt

[in3otd]

thanks; could you please attach also the schematic file (you can rename it to a .txt, it's actually a text file). The netlist above here runs fine - but it might just be due to some small differences in the actual binary code (optimizations, etc.) Which version of Qucs are you running and on which OS?

[AndreaLu]

I'm running Qucs 0.0.19 under Windows 10 64bit. I might have changed something but it's still generating that error. multiplier.txt

[in3otd]

ok, also simulating from the schematic here it runs fine: but it fails when changing a little the simulation end time. I'm using the 0.0.20 release candidate on Linux and as mentioned sometimes we saw differences between platforms - I don't remember any changes to the transient solver for this release.

If you want to try if the latest code behaves differently, you can try the code from here.

[AndreaLu]

I too did experience similar things. I don't know a whole lot of circuit simulation, but if the error is highly time dependant would it make sense, as a temporary patch, to try to avoid the exact time step that generates error? Cause I see this is a very old issue. something like this

• simulate
• error at time step x
• go back a few steps before
• restart simulation from there avoiding the precise error step (just take one a little bit earlier or later)
• cycle

[in3otd]

yes, the issue is very old and unfortunately not much progress has been made. I have some code here locally which tries to improve things but it's not yet stable/fully working. The Qucs simulator already does something similar to what you suggested (and of course spice and others do too and with much more refined algorithms) but the devil is in the details. E.g. sometimes the simulator tries to go back in time and "sees" that it needs to reduce the time step but this can cause numerical issues due to the small differences involved. One thing that should be easy is to tell the simulator to slow down when an independent source, as the pulse generator in your schematic, is about to do a fast change, but also here there are a few pitfalls.