Re: [ng-spice-devel] ACS


To ng-spice-devel@ieee.ing.uniroma1.it
From Al Davis <aldavis@ieee.org>
Date Wed, 1 Nov 2000 12:47:12 -0800
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <14848.12851.604190.102200@pearls >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <39FD4EC9.C2E69668@analog.com > <3A000728.FDE130E4@analog.com > <14848.12851.604190.102200@pearls >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

I think Steve is overemphasizing the importance condition number of
the matrix, or handling it in the wrong place.

MOST circuit matrices are fairly well conditioned.  In my experience,
when a matrix is ill-conditioned, there is usually something else
wrong that led to it.  It is better to address this something else.

Sometimes it is the natural junk you get in early iterations.  This
works its way out as convergence is approached.  It can be a problem
if it prevents convergence, but iterative refinement won't help.

In ACS, if you add the words "trace iterations" to an op, dc, or tran
command, it will show you every iteration.

Another cause is low value resistors that could be replaced by
shorts.  The stray resistors in transistor models are an example of
this.  In ACS, you can turn them off with the option "norstray" or on
with the option "rstray".  By default, it is off.

"shorting" nodes together with a low value resistor can do it.

The various ways to do voltage sources have an effect on this.  I
must admit that ACS uses the worst possible method, which uses a low
value resistor.  Spice uses a subcircuit approach that mimics a
one-graph modified nodal analysis, which is usually a little better
but sometimes worse.  It often gives a zero on the diagonal that
requires a matrix permutation to fix.  Permuting only the rows and
not the columns can give the symptoms of ill-conditioning even if the
condition number looks good.  The best solution here is a two-graph
nullor approach.  Careful node ordering up front is almost as good. 
Still, the effect of this on matrix conditioning is minor compared
other issues.  In ACS, it is easy to see if this is bothering the
solution.  Change the value of the option "short".  If changing it
makes a disproportionate change in the results, this is a problem. 
If changing it makes no change or a trivial change, it is not a
problem.  (I think ACS is generally better designed and more advanced
than Spice, but there are a few points where it misses the obvious. 
It doesn't get in the way of my research ......)

In cases where the matrix is ill-conditioned, you will usually find
that the values in the matrix would be different if it is loaded in a
different order.  Suppose a particular slot is the sum of 10 numbers.
 Suppose that two of them are big, one positive, the other negative,
leading to almost perfect cancellation.  The other 8 numbers are
small.  The error induced by the cancellation of the two big numbers
could be big compared to the smaller numbers in the same sum.  If
they are added in the wrong order, the small ones could be masked
completely.  This would show the same symptom as ill-conditioning,
yet the matrix itself could be very well conditioned.  This error
occurs on construction of the original matrix.  Iterative refinement
of the matrix solution will not help at all.

In this case, the order in which data is loaded into the matrix makes
a difference.  For a given circuit, Spice always loads in the same
order, which you can control to an extent by ordering elements in the
netlist.  Spice always groups elements of a similar type, and the
order of the types is fixed.  I don't know if there is any reason for
the particular order or not.  In ACS, the load order varies.  It may
even be different iteration to iteration.  Usually, only changed are
loaded.

In theory, the ACS incremental update should make this much worse,
but in practice I rarely see any difference at all.  (Try it with
"incmode" turned on or off, and see the difference.  Almost always,
there is no difference, and when there is it is not significant.) 
ACS will do a full rebuild in certain cases where it detects that
this might be a problem.  (usually the big-garbage early iterations).

Since so much depends on building the matrix, any attempt at a final
solution improvement should not use the matrix at all.   Iterative
refinement of the matrix solution misses the biggest errors.  Rather,
it should evaluate the models and sum the currents directly, with the
summing order varying to minimize roundoff error, like a relaxation
based simulator.

In ACS, this should be relatively easy to do.  This is one of the
reasons for separating the evaluate and load passes.  It is also a
reason for the continued use of the theoretically less efficient
subcircuit approach.  Most devices require no new code to do this. 
It is probably worth doing as a study, if only to show that it
doesn't make as much difference as expected, even if it doesn't make
it to the "product".

In Spice, forget it.  Every model will require new code, a nuisance
edit of the "load" function to gather and scatter differently.

Another study that could be done is to use a higher precision data
type for the matrix.  The ACS matrix package is a template class.  It
should not be hard to change the type to long double, or even a
super-precision type defined in software.  This, too, could show how
much effect this issue really has.

If you want to do either of these tests, I will help you.  It is
worth writing a paper on it.  I will do part of this, too.  It is
valuable information that is worth publishing.



Partial thread listing: