Re: [ng-spice-devel] convergence


To ng-spice-devel@ieee.ing.uniroma1.it
From Steve Hamm <Steve.Hamm@motorola.com>
Date Fri, 27 Apr 2001 17:43:18 -0500 (CDT)
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <01042714564808.10628@hobbes >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <CF654D964573D311A1CA0090278A36FF4CBE4C@EDIN_EXM1 ><01042712572007.10628@hobbes ><15081.54410.217878.772132@pearls ><01042714564808.10628@hobbes >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

---"Al" == Al Davis <aldavis@ieee.org> writes:

Al> On Fri, 27 Apr 2001, Steve Hamm wrote:
>> The MNA equations are I(Y1) + I(V) = 0 and V(1) - V = 0.

Al> To do this, you need to solve F(x) again.  This is an expensive 
Al> operation.  That was my point.  How do you get it to be cheap with 
Al> the proper formulation?  CPU time is usually dominated by model 
Al> evaluation.

The KCL check _is_ cheap. But yes, another function evaluation is
needed. Which brings me to another bug in spice: Last time I checked,
it ends Newton in an inconsistent state:

        evaluate F(x_n) and J(x_n)
        solve for x_(n+1)
        if (x_(n+1) - x_n)) is small, quit

So this leaves F having been evaluated at x_n, but the accepted
solution is x_(n+1). So the state variables are off by an iteration.
To correct this, spice needs another function evaluation, too.

Al> I suppose it checks that you have set reltol and abstol reasonably, 
Al> but maybe not.  Due to roundoff, it won't match exactly.  With 
Al> iteration, you don't get an exact solution.  You get it to some 
Al> tolerance.  So, one would expect that KCL would give you within some 
Al> tolerance of zero, as opposed to zero itself.  What tolerance?  
Al> reltol and abstol????  How is this different from comparing 
Al> successive iterations?

I'm not following something here. We're solving KCL for a nonlinear
system as F(x)=0 using Newton. The loop looks like

        evaluate F(x_n) and J(x_n)
        solve for delta x
        if (F(x_n) is small and delta x is small) quit
        x_(n+1) = x_n + delta x
        loop to top

This loop is consistent. Assuming the number of branches and state
variables to be checked is larger than the number of equations -- and
it should be -- the checking is much quicker, independent of the
devices involved, and I still think directly checking F is a benefit,
since that's what we're solving. The number of function evaluations
should be the same, except for purely linear networks (but spice
doesn't do anything special for those).

To actually do the check of F, there have been a number of proposals
in the literature. One could keep track of the maximum branch current
incident at a node and use it for a relative tolerance per equation;
an absolute tolerance could be compared to some norm of F; a
relative reduction in F from F(x_0) could be used.

But, basically, I suppose checking enough things -- including
conductances and capacitances -- for change across iterations should
bound F(). Still it looks more straightforward to check F.

--Steve

Partial thread listing: