#83 Dump Equations
I am performing comparative mathematical studies between the convergence of some circuits in ngspice vs PSPICE vs MATLAB.
To do this, I would really appreciate if ngspice had a feature to "dump" in text form the equations he builds based on the models netlist. For example, if I have a circuit with one resistor R, it would output for both ends (1 and 2) of the resistor:
I(R1) = (V(1) - V(2))/R
I(R2) = -(V(1) - V(2))/R
If I have a condensator, it would say:
I(C1) = Integral(C * dV/dt)
If a diode, it would print whatever the model is behind the scenes. Similarly for a transistor.
Do the developers think this is potentially doable?
Sometimes I have the problem in ngspice (https://sourceforge.net/p/ngspice/discussion/127605/thread/d55d2322f2/) that one circuit converges in one version and stops to converge in another one. If I would be able to compare the equations in text form, I would know which equations were modified, e.g. the pswitch vs aswitch model, and study the numerical behaviour more easily in external tools like MATLAB.
Typo: In I(C1) there shouldn't be Integral, and it should say something along: C * d(V(1) - V(2))/dt
On 2021-05-19 12:51, Ferdy wrote:
Everything is doable, especially if somebody else does it...
Have a look at symbolic network analysis programs (for linear circuits).
SCAM stays close to SPICE, is very easy to use, and a lot of fun:
% This file takes as input a filename (in the variable fname) that
% describes a circuit in netlist format (similar to SPICE), and then
% performs a symbolic analysis of the circuit using Modified Nodal
Analysis
% (MNA). A full description of MNA and how to use this code is at:
% http://lpsa.swarthmore.edu/Systems/Electrical/mna/MNA1.html
%
% Written by Erik Cheever, Swarthmore College, 2019
% echeeve1@swarthmore.edu
It is not possible to handle non-linear elements in this way, and that
is actually why SPICE exists.
-marcel
Related
Feature Requests: #83
Thanks Marcel for the reply and the link.
However, my idea was to apply this for non-linear systems (diodes, transistors, etc). I do not want to get the solution or matrix of the equation system, just the equations printed out in a human-readable way.
So to say, something in text form like:
So that I know for example which diode equation is being used and is affecting numerical stability, etc. In fact, I would not need to this for a full circuit, just for the basic models (R, C, L, Switch, Diode). Either in symbolic form with the model parameters Ron, Roff as a letter, or directly with the numerical values passed to the model substituted.
As I believe that ngspice already has some of this defined behind the scenes, I was wondering if there would be a way to 'dump' this information out as a .txt file. Something like ngspice-dump ASWITCH. Of course, I could potentially dive into the manuals, literature references and codes to find out what is going on for every model, but it would be more convenient to have a more generic solution to the problem.
On 2021-05-19 15:25, Ferdy wrote:
One problem is that SPICE keeps the MNA matrix in sparse format, and factors it before doing NR iterations. I have tried to track this process, but it was extremely difficult. Luckily I found better ways to do what I wanted and could happily abandon that experiment.
The second problem is that you are expecting continuous-time differential equations, while SPICE approximates these with discrete-time difference equations which look more like Z-domain transfer functions (if the timesteps were uniform, which they are not).
Understanding numerical problems with SPICE is indeed easier when one knows what is going on behind the scenes. Unfortunately, mastering that domain is a decade-long project in itself. Given that many people understand SPICE well enough for their purposes
is a sign that your chosen route may not be the shortest one.
-marcel
Last edit: marcel hendrix 2021-05-25
Thanks for the detailed reply, I understand.
It would be fine for me, too, if the tool printed the discrete-time difference equations instead of continuous ones.
I just have sometimes the feeling that ngspice is a black box, and being able to just read the equations would make it easier to understand some behaviors (not necessarily solving them).
Also, I do not necessarily want to exactly reproduce the equations and approximation that ngspice actually uses. It would be also fine to know the model equations 'before' approximations and in DC mode. That would already make it more understandable even if the problem might happen later in the approximation process.
But yes, this might be a too large effort, I agree...
The best way to see the circuit matrix is to debug dctran.c, cktload.c and examine the CKTcircuit structure. Also you can examine the code-model for some issues. Most non-convergence issues can be divided in such categories:
1) a shorted ideal Voltage source with no series resistance (when the current is infinity which breaks the matrix). A capacitor can also cause problems when shorted.
2) an open ideal current source with no parallel resistance (when voltage becomes infinity). An inductor can cause problems as well when left open. BTW, in real world an overvoltage on the nodes of an inductor can burn a component, and in simulation you will see a few kVolts, so the oscilloscope and simulation diagrams will differ much.
3) signals with infinite slopes with capacitors/inductors. These can cause the simulator to go mad and jump back and forward around the solution but never converge.
4) the floating point double time. in some cases the circuit can converge when time is relatively small (t < 1 s) but will fail when time is large (t > 10000 s) this is caused by the nature of floating point numbers.
5) a code model is used or developed not carefully (negative resistance occured, negative differential resistance occured, which makes the circuit unintentionally oscillating). Btw capacitors or inductors can solve this issue and you will actually see the oscillation. Negative differential resistance is not always a bug, in some cases it actually provides the possibility to make a desired oscillator.
Also the type of integration matters. A trapeze integration method is more unstable (which benefits oscillator circuits) and a gear method is more smooth (which benefits amplifier circuit). There are trade-offs and pitfalls at every corner here :)
upd. if you want more info - read Leon's Chua "Computer-Aided Analysis of Electronic Circuits". This is like a holy grail in electrical engineering CAD software.
Last edit: Yurii Demchyna 2021-05-24
Thanks Yurii for the detailed answer and the reference to the book.
Actually, the convergence problems I am seeing is in DC (constant) simulation mode, thus I believe it is not a problem of capacitors. It happens when using diodes and/or transistors. At some points in the DC sweep, I think that the diode or transistor (which may use aswitch or pswitch) go through a discontinuity in the derivative which causes these problems.
What I was suggesting is to have a way to check the original equations, potentially prior to integration methods, Taylor expansion, etc. Either through detailed description in the manual, or through a "dump()" function in every device that prints out the equations as text form to terminal. This information could be used in some corner cases where ngspice is not robust or does not converge, to feed it into another external program, e.g. Matlab, to see if it converges there or where the convergence issues might come from, to understand it at least from a qualitative point of view.
Last edit: Ferdy 2021-05-24
Ferdy, what do you mean by using diodes in transistors? If we apply those categories from my previous message, they are still valid for DC sweep analysis.
1) For open mode of a junction. A transistor or a diode don't like to be shorted by an ideal voltage source, cause their current grows exponentially and can go up to infinity or very large floating point numbers with high delta between adjacent numbers, which makes the equation not solvable.
2) For reverse mode, a diode or transistor don't like to be open circuit with an ideal current source. This causes the voltage to increase exponentially.
Models in different simulators can have built-in parasitic parameters (parallel/series resistance) which help to converge the circuit. Matlab can have better precision for floating point arithmetic etc.
For example if a junction current for every 10 mV doubles, then it will be multiplied 2^100 per volt. and 3 volts will be enough to cause a matrix convergence issue, cause maximum double value is 1.7e308. A more realistic model can have some mOhm series resistance which creates an upper limit for the current, so it will not cause convergence issues.
Thanks Yurii. Sorry, that was a typo, I wanted to say diodes "and" transistors.
I use 'commercial' SPICE models of the actual transistors and diodes I put in the PCB, hoping that they are realistic enough (downloaded from the vendor website). What surprised me is that the convergence was fine for an older ngspice version but not for a recent one, for the exact same circuit (due to pswitch aswitch change, see https://sourceforge.net/p/ngspice/discussion/127605/thread/d55d2322f2). This non-robustness is what motivated me to put this feature request.
On 2021-05-24 21:45, Yurii Demchyna wrote:
A very nice summary, worthy to include in the FAQ.
Tiny comments:
Ad 1) I seldom see people add series resistance to their voltage sources while using GMIN (to counteract (2)) is more or less a standard procedure.
Some authors are very vocal in condemning all voltage sources and pleading for a Thevenin alternative with a small capacitor in parallel.
Ad 2) See 1. Solves almost all problems not related to discontinuity.
Ad 3) My type of work (power electronics) confronts me with this problem almost daily. Can be solved with STEPMAX, at the cost of speed. Sometimes it is necessary to change equations that are not defined outside of their domain (e.g. square roots of negative values), because the simulator will deliver almost any input at some point (e.g. a negative current through a diode that is supposed to be OFF).
Ad 4) Never seen this in isolation. Some simulators allow to use an integration method with higher precision (80bits, I've not seen 128 bit yet). Not sure if it helps because of the higher range, or because of the higher precision.
Ad 5) Never seen this or realized it was the problem. Example?
Ad 6) TRAP / GEAR / EULER. For my work TRAP causes more problems than it is worth. Indeed, HF oscillators may appear not to work with TRAP. Can be embarrassing when one doesn't know what the simulation result should look like. (It works both ways, TRAP ringing is visible in many students' assignments.)
-marcel
Last edit: marcel hendrix 2021-05-25
about 5)
once I worked with a poorly measured VI of a transistor. The numbers were in a B source.
highest current of linear region was little larger that the saturation current. The circut failed to converge.
and in some cases that negative part of the VI resulted convergence when Vdrain was hundreds of volts.
Best regards,
Yurii
Last edit: Yurii Demchyna 2021-05-25
As an alternative solution, it might be interesting to add the model equations to the ngspice manual for more components. (Or in a separate appendix).
For example, I see that this is already very well explained for the diode, section 7.3.
It would be great to have a similar description for "aswitch" and "pswitch", as well as for the MOS models, as done e.g. in https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-012-microelectronic-devices-and-circuits-fall-2005/projects/spectre_mos1_mod.pdf
Last edit: Ferdy 2021-05-24
Unfortunately your link to the MIT course is a dead link.
It is probably only the trailing dot which creates a problem.
Thanks for pointing out, fixed now.
To become a little more pratical:
Indeed the switches (aswitch and pswitch code models), which are used to emulate the PSPICE or LTSPICE vswitch, are a source of concern. I will have another look at both. Most current OpAmp models (especially the TI versions) rely on these switches somehow, and we have convergence problems.
Ferdy, would you like to contribute? I need an independent look at the source code and would be happy about some suggestions. We are in need of a smooth output function versus input, covering a large range (several decades). And we need a carefully designed (calculated) derivative. The source code (in XSPICE syntax, close to C with some macros added) can be found in
ngspice\src\xspice\icm\xtradev\aswitch\cfunc.mod
and
ngspice\src\xspice\icm\xtradev\pswitch\cfunc.mod
One may find some hints in the PSPICE or LTSPICE manuals, but of course no source code.
Holger, the convergence issues can be caused by resistance limiting in the middle of aswitch model.
A derivative is calculated based on the cntl_in. In the middle of the model resistance is limited when the voltage goes out of bonds and voltage is not limited. This can cause a discontinuity between output resistance and control voltage. I think that the input voltage must be limited so that resistance will automatically be in correct range and the derivative will be continuous as well
Last edit: Yurii Demchyna 2021-05-25
On 2021-05-25 10:37, Yurii Demchyna wrote:
I think one needs to allocate a state variable for the switch. Without
this, SPICE has no idea what to do when stepping back in time while
in the area between the switch threshold V- or I-points. The way I do it
now is by keeping a record of the previously simulated points and infer
(extrapolate) the state from them. It works but it is far from elegant.
-marcel
Marcel,
would you mind to publish your switch model here?
Holger
Hi Holger, good idea. I would be happy to contribute and take a look. I will also discuss it with my colleagues from the applied mathematics department.