gnucap-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]