Re: [Gnucap-devel] Local truncation error

[Al Davis]

On Wednesday 26 November 2003 10:38 am, Dario D'Amore wrote:
> I'm making some tests using gnucap with power electronic circuits.
> I have few questions:

> 1) Working around inside the code I found that in case the
> integration method used is the Backward Euler, gnucap does not check
> the LTE. I do not understand the reason of this choice. Can you spend
> a minute to give me the reason why?

It is deliberate.  The reason for choosing euler is to give preference 
to absolute stability over truncation.

Trap is perferable to Euler in any case where truncation error matters.  
The down side of Trapezoid is that it generates artifacts that give the 
illusion of instability when the step size is too large.  The LTE check 
is supposed to control this.  Usually it does.  Trapezoid works poorly 
for the stiff case, with widely varying time constants.  The LTE check 
forces a time step that is unreasonably small to avoid artifacts on 
strays that you really want to ignore.

Remember that a simulator really works in discrete time.  The 
integration/differentiation in effect maps the continuous time S domain 
to the discrete time Z domain.  If you look at the root locus, it is 
well known that poles on the left side of the S plane indicate a stable 
system, and on the right indicate an unstable system.  On the Z plane, 
the system is stable with poles inside the unit circle.  The different 
methods use a different mapping between S and Z.

The trapezoid method maps the j-omega axis in S exactly to the unit 
circle in Z, so the stable to unstable border maps exactly.  This may 
seem ideal, but it isn't.  Consider a single pole.  If you start with 
it at the origin of the S plane, and move it toward negative infinity, 
you will see the time constant becoming faster, eventually becoming 
fast enough that you ignore it and consider it to be instantaneous.  Do 
the same on the Z plane.  Start it at (1,0), (where S 0,0 maps) and 
migrate it along the real axis toward (-1,0) (where S = -infinity maps) 
you see a different behavior.  The time constant becomes faster, 
becoming zero at (0,0).  So, at (0,0) the response is instantaneous.  
This does not map to (S = -infinity).  Move it further in the negative 
direction, the response increases again, with alternating samples.  
Strictly, it is stable, but the response is very unlike the response of 
a real system.  If the point is close to (-1,0) you will see strong 
ringing at the folding frequency, when the real system is giving a well 
controlled response fast enough that you want to think of it as 
instantaneous.  LTE control is necessary to keep all such cases on the 
right side of the Z plane.

The Backward Euler method uses a different mapping, that maps the enitre 
left half of S to a circle that is completely within the unit circle of 
Z, and on the right side, that is with a positive real part.  The 
result is that a pole near minus infinity on S maps to near (0,0) on Z, 
giving a correct response which is nearly instantaneous with no 
ringing.  LTE is poor, but it doesn't matter. 

So, you should choose backward Euler for strays, where you do not need 
accurate modeling, but do not want the artifacts that trapezoid causes.  
It is usually accurate enough for strays in digital circuits.  If the 
effect of a capacitor is significant, the LTE is inherently good 
enough.  If the effect is not significant, it in effect disappears.

> 2) What is the exact reason for wich you use a table for selecting
> the actual integration method? An element can impose a particular
> integration which wins over OPT:method? is it correct?

The intent was that it is selectable per element, but that is not fully 
implemented.  All that is missing is the ability to specify it.  The 
original plan was to add a keyword "stiff", which says to use backward 
Euler and ignore truncation error.  I also planned to add the ability 
to explicitly specify the method.  This is similar to the way Spectre 
(Cadence) does it.

Gear's method is also planned.  It is easy to do.  I just ran out of 
time.  I am not sure whether Gear's method should do LTE checking or 
not.

> 3) Do you plan to improve/modify the model generator (and related
> documentation)?

Yes.  What improvements would you like?