Re: [Help-gnucap] Time step control

[al davis]

On Saturday 16 February 2008, a r wrote:
> Last time I tried Gnucap (in November) I thought I've finally
> managed to make its time step control working but it looks
> like I haven't tested it well enough. I would appreciate any
> ideas how to improve it.

Time step control is one of the more difficult aspects of 
circuit simulation.  The only way to know is to try lots of 
circuits.  

In tests I have run, it is far from perfect, but on the average 
appears to be somewhat better than Spice (3f5 or NG).  I have 
seen several cases where Spice gives you believable but 
incorrect results.  On those same cases, gnucap either 
explicitly fails, gives a warning, or works correctly.

Can you send me the one that is giving you trouble?

> Problems:
>
> 1. Using euler method:
>
> With following options my simulation runs (although waveforms
> are slightly distorted, see: 1a)
> .option method=euler dtmin=1e-15 abstol=1e-13 vntol=1e-7
> chgtol=1e-15 reltol=1e-5 itl3=4 itl4=20 trstepgrow=1.5
> trtol=0.1
>
> Tightening time step (itl4=10):
> .option method=euler dtmin=1e-15 abstol=1e-13 vntol=1e-7
> chgtol=1e-15 reltol=1e-5 itl3=4 itl4=10 trstepgrow=1.5
> trtol=0.1

You changed ITL4 from 20 to 10.  This is not a good idea.

For other readers:
ITL4 is the maximum number of iterations on a transient step.  
If it takes more iterations than that, the step is rejected, 
time is backed up, and it tries again with smaller time steps.

This is used as last resort method of recovering from a 
convergence failure.  Iteration count works poorly as an 
accuracy control mechanism.

> improves results (waveforms are smoother)

By smoother waveforms, I assume you mean that you see line 
segments on a plot, or explicitly want smaller time steps.  If 
this is the case, you need to manually specify it.  If you are 
referring to "artifacts" that is where the auto time step 
should come in.

"method=euler" tends to make waveforms artificially smooth.  The 
artifacts are like information loss, or as if L's and C's were 
less significant.

> but the simulation 
> fails with: very backward time step
> convergence failure, reducing (itl4)
> newtime=8.009999e-09  rejectedtime=8.010000e-09 
> oldtime=8.009999e-09 using=8.010000e-09
> tried everything, still doesn't work, giving up

Convergence failure -- itl4 ....

I need to reword that message.

It says that for good results you need to increase ITL4.

> Odd, isn't it? There is nothing special in the circuit to
> make it fail at this time (it happens either with inductors
> included or removed from the circuit, see:

There is something special in the circuit to make it fail at 
that time.  Something is going through a very nonlinear region, 
most likely a discontinuity or bifurcation.  No matter how 
small the time step is, it will not converge in 10 iterations.

You might consider to "trace iterations" which will show every 
iteration.  There is way too much information, but if you just 
look at the last step it might show what the problem is.  Most 
likely, it just needs more than 10 iterations.

I have never seen a case where decreasing ITL4 makes things 
better.  I have considered making the default higher.

> 2b). I am using my 
> modified bm_pulse model here so this error may be related to
> its event scheduling.

probably not.

> 1a. trstepgrow settings
>
> If I do not limit trstepgrow to 1.5, the simulation tends to
> take far too large steps.

trstepgrow is intended only to temporarily put tighter control 
during a recovery period.

> In fact circuit state is calculated 
> only at time points forced by independent voltage source
> transitions.

You asked for Euler, so it assumes that this is what you want.  
That is why you would use Euler. ...   To relax the accuracy of 
charge effects to make it faster or to relax only certain ones 
like strays that don't really matter.

> Limiting trstepgrow "fixes" this behaviour by 
> slowing down the process of increasing time step, so if there
> is some activity immedately following an independent voltage
> source transition there is a chance it will be simulated
> accurately. Unfortunately when the circuit activity occurs
> spontaneously of after some time from the most recent
> independent voltage source transition the time step happens
> to b.
>
> It makes me thinking that there is nothing in device models
> (bsim_310 here) that would decrease time step when the device
> state is not settled.

bsim_310 uses generates only truncation error time step control, 
which is disabled when you use Euler.

There are plans to add threshold crossing time step control to 
the spice models, but it isn't done yet.  Spice doesn't do it 
either, and the common "ADMS" model compiler, which was used to 
generate some of the Spice C models, doesn't support it.

For now, you can add a switch to the circuit, with a threshold 
at the trouble spot.  Connect only the input.  Ground both 
output terminals.  If you do this, gnucap will find that 
crossing to high accuracy.

s11 (0 0 n1 n2) control_hack
.model control_hack sw vt=5
(if you want an event when the voltage crosses 5)

> 2. Using trap method:
> .option method=trap dtmin=1e-16 abstol=1e-13 vntol=1e-7
> chgtol=1e-15 reltol=1e-4 trtol=0.001
>
> 2a. I get a lot of following warnings (bsim310 devices):
> storage element step control error:xtr.xn3.Mn 7.24208e-19
> using Euler, disabling time step control

This is just for your information.  

Make believe it says:

"xtr.xn3.Mn is too small to really matter, so I am being sloppy 
about it"

So how does it decide what is too small to really matter? ....

There is an option "dtmin", which sets the minimum acceptable 
step size.  If the suggested step size is bigger than dtmin, 
use it.  Otherwise, use Euler for this element and do not 
consider its truncation error in time step control.

> AFAIR, there were no such warnings when I tried
> gnucap-20071121.

Probably the error reporting threshold was set different.

> 2b. If there is an inductor element in the design (a series
> LR connection modeling a wire) the time step control becomes
> very unstable - very small time steps, numerical
> oscillations. 

Using trap, time steps will be small.  The "trap artifacts" are 
really like aliasing.  The time step is too big for the time 
constant.  As I recall, the simulator time step must be no 
bigger than half of the time constant of the RC, even for tiny 
capacitors you want to ignore.  Truncation error based step 
control should take care of this.

With Gear-2, the time step would be (as I recall) about a 
quarter of the trap time step for similar accuracy, but the 
artifacts are different and usually less visible.  In this 
case, Euler is more accurate and has even less artifacts.

So that "using Euler" warning you see is from an attempt to use 
trap where you need the accuracy and Euler where you don't, 
automatically.

> I am pretty sure these oscillation do not come 
> from the design (all second order circuits are strongly
> damped). Removing inductors solves this numerical stability
> problems.

> I can reduce the amount of these oscillations by using
> default simulationoptions (.option method=trap) i.e. by
> relaxing some tolerances. 

> It does not solve my problem 
> though, as numerical oscillations still force a small and
> constant time step.

Try increasing dtmin, and tightening chgtol and trtol.  Set 
trtol=1.

I don't have the netlist, so I can only guess.  Different types 
of circuits need different tolerances.