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

[al davis]

On Thursday 29 November 2007, a r wrote:
> Adding second order methods to Gnucap is beyond my
> capability. I've been trying this a while ago and gave up
> pretty soon.

As I said, it's even harder with dynamic non-local time 
stepping.

> As for the backward Euler method, doesn't it give
> overoptimistic results for inherently unstable circuits? 

Yes.  Predictably so.

You might think of the higher order methods as starting with 
Euler and attempting to correct it.  Trap and Gear differ in 
the details of how they do this.

Gear also gives overoptimistic results for inherently unstable 
circuits.  When error is low, it is not quite as overoptimistic 
as Euler, but there are other artifacts.  The artifacts are as 
big as the trap artifacts, but tend to be of a believable form, 
so you don't see them.

Trap gives priority to being correct in this case, with the cost 
of very obvious artifacts when the time step is way too big.

Personally, I would rather the simulator tell me when it knows 
it is wrong.

> In 
> my circuits I usually have lot of passive devices modeling
> interconnections and I do want to see any real ringing that
> may occur in the circuit.

Internally, gnucap can use different methods for different 
devices.  I have not yet made a good method to specify it.  
Maybe it should become a priority.  It makes sense to use trap 
for deliberate capacitors and Euler for strays.

> I couldn't find any option for tightening accuracy. The only
> one I saw was 'roundofftol', are there any other?

reltol, abstol, vntol, trtol, chgtol ... works as documented, 
and as documented in Spice.  (as opposed to how Spice really 
works).

The significant ones here are chgtol (charge tolerance) and 
trtol (truncation error calculation fudge factor).  Try option 
trtol=1.  This will make it run slower, because it is doing 
more time steps.

I debated what should be the default value for trtol.  The 
default is 7, which is Spice compatible, which means to allow 7 
times as much error in charge as the formula predicts.  Still, 
it isn't really the same as Spice because the truncation error 
formula in Spice is incorrect.  It isn't off in a consistent 
way.  It is just plain wrong.  Some of the commercial Spice's 
are wrong too.  It's the same code.  It was wrong in Spice-2, 
and identically wrong in Spice-3.

In gnucap, the development version (since 2006-06-28) and the 
stable 0.35 are correct.  Versions before that had the same 
error that Spice had.  Back then, I didn't really analyse it.  
I just based it on the Spice algorithm.  In 2006, I was working 
on getting accurate simulation of oscillators.  If you tighten 
the tolerance, it is accurate enough that you can get a 
meaningful distortion analysis of a sine wave oscillator.  
Spice has a residual error that won't go away no matter how 
much you tighten the tolerance.

> BTW, does Gnucap attempt to verify 
> Kirchhoff's laws prior to accepting the timestep result (as
> Spectre does)?

Yes, and it uses the information to make it run faster.