Re: [Help-gnucap] Time step control

[al davis]

On Monday 18 February 2008, a r wrote:

> What I expect from good time step control is (conceptually)
> simple: 
> 1. Adjust time step so that local truncation error is 
> constant (slightly less than specified value),
> 2. Limit time step to such value that numerical instability
> will not occur.

In theory, 1 implies 2, 2 does not imply 1.

Local truncation error is only one aspect of step control, 
probably not the most important in this case.

There are some others, like controlling voltage error, 
controlling dv/dt, and more that are not implemented.  I want 
to do it, and know how.  It just takes time.

Also, it takes test cases.  I need test cases that demonstrate 
the problem, so I can see it, and confirm that the method meets 
the goal.

> decrease time step at "difficult parts". Later you wrote:
> > bsim_310 uses generates only truncation error time step
> > control, which is disabled when you use Euler.

I did not create that model.  It came from Berkeley and does 
what they chose to do.

> which looks like a direct reason of this problem. I would
> much more prefer to have the time step control enabled for
> _any_ kind of transient analysis. Constant time step is a
> serious limitation for me.

Time step control is always enabled.  When you ask for Euler, it 
is not based on charge based truncation error.  All other 
aspects still work.

Consider this circuit:

R1 (1 2) 1Meg
C1 (2 0) 1u
R2 (2 3) 1
C2 (3 0) 1f

There are two time constants.  One is 1 second.  The other is 1 
femtosecond.  Strict step control would give a step size of 
less than 1 femtosecond, likely about .1 femtosecond.

What gnucap would do is to sense that the step required by R2C2 
is too small, switch C2 to Euler, and not consider it for step 
control.  Now the step control is strictly based on R1C1.

Such a spread is very real.  The slow time constant is likely to 
be something you designed.  The fast time constant is likely to 
be the result of strays that are so small you ignore them when 
you manually analyze.

Truncation error step control for Euler always gives very small 
steps, significantly smaller than the steps used for trap.

Euler will never give you ringing artifacts.

> I _still_ can see quite a lot of numerical ringing but its
> amplitude is now small enough so I can ignore it (and
> frequency is low enough so it does not slow down the
> simulation). 

If you can send me a sample circuit, I will look at it.  You 
don't need to post it.

I suspect that chgtol is still too large.  1e-15 = 1 
femtocoulomb.  That's 1 volt on a 1 femtofarad capacitor.

It points out the need for error control that is not based on 
charge.

> I think the threshold between trap and euler 
> methods for "storage elements" (strays etc.) should be placed
> slightly higher than dtmin (say 2~3 * dtmin). It looks for me
> that currently the minimum time step is always a bit too
> large for those strays that have passed just under dtmin
> threshold, hence the numerical ringing.

That is easy to do.  I think I will. There needs to be a 
difference between minimum resolvable time and the stepping 
from truncation error.