[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] A follow up to a question from a while ago.
From: |
al davis |
Subject: |
Re: [Gnucap-devel] A follow up to a question from a while ago. |
Date: |
Fri, 22 Aug 2008 19:42:36 -0400 |
User-agent: |
KMail/1.9.9 |
On Tuesday 19 August 2008, Thaddeus Meizelis wrote:
> I have used the diode in a schematic I was using for an
> analysis, but it seemed to break during the the transient
> analysis (very backwards time step.) I don't know if it is
> my model or if it is something else (none of the diodes were
> in breakdown,) but if it is the model I'll let you guys know.
I really need to change that message.
Usually it indicates a convergence failure in the middle of a
transient analysis.
When the solution does not converge in a certain number of
iterations (ITL4), the step is rejected, time backed up, and it
makes another attempt with a smaller time step. If this is not
successful, make the time step even smaller.
In most cases, this fixes it, and you don't even notice the
tricks. If the retries are successful, you don't even get a
warning about it.
The failure you noted occurs when this doesn't work. Even with
a time step of essentially zero, it still fails to converge. I
have observed two different conditions that sometimes lead to
this.
The first is a bad model. If a model has a discontinuity it
will hop back and forth across the discontinuity, never
reaching a solution. For good convergence, models need to have
good numeric properties, even in cases that can never happen in
real circuits. Those cases can happen as trial cases during
iteration.
If you look at model code, often you will find an "if"
statement:
if (a > 7.6) {
b = a * 12;
}else{
b = 13.9;
}
In a good model, approaching the break from either side will
result in the same result. In this case, that means 7.6 * 12
must be equal to 13.9. I hope you see that this one doesn't
meet the requirement.
So, check the model at the boundaries to make sure this
condition is met. Usually, the computed value and its first
derivative should meet this requirement. For the evaluate
functions in gnucap, this means the "f0" and "f1" should both
be smooth.
The other condition that often leads to something like this is
something strange happening in the circuit. In a diode
circuit, consider a full wave bridge. At v == 0, all diodes
are open. You could have nodes that are floating during this
time with no reference. There is an option "gmin" which adds
conductances to ground everywhere, that usually takes care of
things like this. The default value (1e-12) is designed around
small-signal, high impedance circuits. In a power supply, gmin
can be so small as to be essentially zero, so you still have
the problem. Try making gmin bigger. If you make it, for
example, 1e-3, it is equivalent to putting a 1k resistor to
ground everywhere. You need to choose a value that will fix
the problem but not significantly degrade accuracy.