[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnucap] Re: Scientific/engineering notation
From: |
al davis |
Subject: |
Re: [Help-gnucap] Re: Scientific/engineering notation |
Date: |
Thu, 29 Nov 2007 21:59:04 -0500 |
User-agent: |
KMail/1.9.7 |
On Thursday 29 November 2007, a r wrote:
> OK, I've found the solution:
>
> .probe tran v(in) v(n1) v(out)
>
> .dc
> .tran 1n 4u >out.dat
>
> Looks like .probe and .print commands work same in this
> context. Before I was trying to redirect the .print's output
> to the file instead of redirecting the analysis (.tran)
> itself.
They are the same. There is a historical reason for it. It was
originally "probe" only, then "print" was added for "spice
compatibility".
At that time, the "spice compatibility" goal meant that it would
be possible to make files that worked in both. It was never
intended for gnucap to be like a spice clone. There are
features of the gnucap way that I cannot give up.
> BTW, I am getting pretty strong numerical ringing in this
> analysis. AFAIK, gear method is not yet implemented. Any
> chance for this?
For now, try "method=euler".
The Gear method is almost never the best choice. It is popular
because it is often the second choice. If trap is giving you
trouble and Gear would fix it, Euler would be more accurate.
If Euler is not accurate enough and Gear is better, trap is
even better.
Specifying Euler disables the truncation error part of time step
control. This is what you want.
If you really want it to be accurate, tighten the tolerances to
make it stop ringing.
It may seem counterintutive that a first order method would be
more accurate than a second order method, but in this case,
it's true.
Consider this:
First order means error is proportional to something quantity I
will call "h".
Second order means error is proportional to h^2.
Which one is smaller depends on the value of h. People think
the higher order method is more accurate because when h is
small, h^2 is even smaller. They forget that when h is large,
h^2 is larger. For accurate simulation, h is small. When you
see trapzoidal ringing, h is large. The actual error with
Gear's method is higher than trap (more correctly "Huen's
method"), but it is in a form that is less apparent.
If you want reasonable results with a time step that is too
large for the time constant, use Euler. This is a reasonable
request. Strays often are in this category, you would like to
ignore them. Euler errs reliably in the direction of ignoring
them.
As to any chance for adding the Gear method ,,,, I have no
objection to including it as an option, but I have other higher
priorities for now. If you (or anyone reading this) want to
add it, and can show that it is correct, I will welcome the
addition.
It's not as simple as it seems. It is harder in gnucap than in
Spice, because time stepping in Spice is global. All devices
share the same set of time steps. In gnucap, time stepping is
local. Different devices can have different time steps.
The issue for Gear is computing the coefficients with unequal
steps, When stepping is uniform, you can look up the
coefficients in a table, It's easy. When stepping is
non-uniform, the coefficients must be calculated, possibly for
every step, and since time history is local, for every device.
If you forget about this, you may not see the error, because
usually stepping is synchronous, and will hide the bug. Then
occasionally you get a spike of really strange results that
can't be explained.
One possibility I have considered is a Spectre-like "trap-gear"
or "gear-euler" method, where it switches methods on the fly,
using Gear when it is easy and switching to something else when
it causes trouble.
I'm getting technical here ...... It is because of these
subtleties that I didn't do it already.