[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Local truncation error
From: |
Al Davis |
Subject: |
Re: [Gnucap-devel] Local truncation error |
Date: |
Wed, 26 Nov 2003 18:39:52 -0500 |
User-agent: |
KMail/1.5.4 |
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?