From: al davis <ad212@fr...>  20130721 02:14:52

On Thursday 18 July 2013, Soeren D. Schulze wrote: > Thanks. I checked gnucap, which does the same thing, and if > I can trust some random web articles, Spice does it, > too. I haven't used Spice that much, but convergence seems > to be a bit better there, which I now can't explain any > more. Yes, that's the way they do it. Can you show me an example of a real working circuit that fails to converge in gnucap? I know that some do not converge. I want examples that I can study. As to Spice ..... often the models are the same, and in this case I expect convergence to be the same. Sometimes there are differences such as time stepping that result in convergence on one, and nonconvergence on the other. Convergence checking is not as strict in spice, so I have seen a few cases where gnucap reports a convergence failure and spice does not, but gives incorrect results. Which would you rather have .... a simulator that correctly tells you when there is a problem? .. or a simulator that glosses over it, giving you an incorrect result and the feeling that all is well? What behavior is correct for a circuit that does not have a stable DC operating point? > This is a bit surprising to me. For my Bachelor's thesis, I > had primarily looked at mathematical literature on this > topic, and they all write down the equation globally and > then apply some standard solver, avoiding the condition > problem. That works great for the simplest of simple problems. For the complex issues in circuit simulation there are other issues, leading to a need for a more heuristic approach. What you are talking about might have been state of the art about 1970, before Spice. As a challenge to you .... Here's a really simple circuit, with some commands to analyze it. It should run in any simulator that supports spice syntax. I am curious what other simulators say, and how your algorithm would handle it. Gnucap gives a correct result. NGspice and LTspice do not. The "*>" lines are gnucap postprocessing commands. It calculates the period, rise time, and fall time. * switch as negative resistance oscillator SW1 1 0 1 0 SWITCH1 C1 1 0 1n I1 0 1 100u .MODEL SWITCH1 SW VT=2.5 VH=2.475 RON=1 ROFF=10MEG .print tran V(1) *>.print tran + r(SW1) iter(0) timef(sw1) control(0) *>.store tran v(1) .option method=trap numdgt=9 .tran 100e6 200e6 uic trace all *>.measure t2=cross("v(1)" cross=2 fall last) *>.measure t1=cross("v(1)" cross=2 fall last before=t2) *>.measure t0=cross("v(1)" cross=2 fall last before=t1) *>.measure tmin0=min("v(1)" arg last after=t0 before=t1) *>.measure tmin1=min("v(1)" arg last after=t1 before=t2) *>.measure tmax1=max("v(1)" arg last before=t1 after=t0) *>.param falltime=tmin1tmax1 *>.param risetime=tmax1tmin0 *>.param dt=t2t1 *>.eval falltime *>.eval risetime *>.eval dt .END > Apparently, electronic engineers and mathematicians don't > talk to each other enough... Yes .. the mathematicians could learn a lot from the engineers if they would talk more. 