Re: [Help-gnucap] Time step control

[al davis]

On Tuesday 19 February 2008, a r wrote:
> On Feb 19, 2008 6:19 AM, al davis <address@hidden> 
wrote:
> > If there are no storage elements, there is no truncation
> > error, but there is still "activity", and step control is
> > still needed.
>
> I agree it doesn't work well in every case but for most
> circuits (i.e. those with storage elements) truncation error
> is a reasonable estimation of the circuit activity. You are
> using it in trap method after all and it works quite well
> (except for ringing which is an inherent "feature" of trap
> method).

With noncritical circuits, a lot of things work, even if it is 
round-about.  Unless you are doing critical analog work, where 
noise, distortion, and accurate timing are all important, 
truncation error is a round-about method.
>
> > For the future, there are plans to add node-voltage-change
> > based time step control.
>
> That would be great, assuming it'd work reliably without
> manual intervention. However, I see it as a great supplement
> for the LTE based time step control, not a replacement for
> it.

It will be a supplement, not a replacement.

> > Truncation error is only loosely related to circuit
> > activity, usually too little, too late.  That is why it is
> > still possible to see trap ringing sometimes.
>
> What other simulators are using (spectre, hspice etc.)?
> Whatever it is it works well enough for them - I've never had
> to fiddle with their time step control options except for
> some tricky circuits.

Spectre is strictly voltage based.  I think HSpice is now too, 
but it may have old spice truncation error based code still 
there.  Most of the "fast-spice" simulators are voltage based 
only, and use Euler's method.

>
> Again, I am quite satisfied with the results of trap method.
> There are some numerical artifacts but I can live with them.
> I would only wish euler method to perform similarly well -
> currently it is only usable for fixed time step transient
> simulations.
>
> BTW, is it possible to enable LTE check in euler method in
> the source code? If it's not very difficult I'd like to test
> it a bit.

In the development snapshot, e_storag.cc, line 250.  Make it 
always false.  Perhaps there should be an "option" to turn it 
back on, but it worked so badly that I decided it was better 
always off.  While it worked so badly, I did prove that it was 
correct.

Years ago, I did try to implement Gear's method, and ran into 
problems with automatic step control.  Gear's method is easy 
when step size is uniform.  It is manageable when step size is 
non-drastic and global.  It is harder when step control is 
drastic and local, so I didn't go any farther.  I started to do 
a mixed approach like Spectre does, so the framework for it is 
in place, but other things had higher priority.

The usual approach is to resample with uniform step size, which 
increases the truncation error to essentially what you would 
get with Euler.  The correct approach is to recalculate the 
coefficients.