Re: [Help-gnucap] Re: Scientific/engineering notation

[al davis]

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.