[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnucap] Time step control
From: |
al davis |
Subject: |
Re: [Help-gnucap] Time step control |
Date: |
Sun, 17 Feb 2008 21:28:39 -0500 |
User-agent: |
KMail/1.9.7 |
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.
- [Help-gnucap] Time step control, a r, 2008/02/16
- Re: [Help-gnucap] Time step control,
al davis <=
- Re: [Help-gnucap] Time step control, a r, 2008/02/18
- Re: [Help-gnucap] Time step control, al davis, 2008/02/18
- Re: [Help-gnucap] Time step control, a r, 2008/02/18
- Re: [Help-gnucap] Time step control, al davis, 2008/02/19
- Re: [Help-gnucap] Time step control, a r, 2008/02/19
- Re: [Help-gnucap] Time step control, al davis, 2008/02/19
- Re: [Help-gnucap] Time step control, a r, 2008/02/19
- Re: [Help-gnucap] Time step control, al davis, 2008/02/19