Re: [Gnucap-devel] method and error (was: transient -- "trace" default)

[al davis]

On Tuesday 07 January 2014, Felix Salfelder wrote:
> this makes sense, as long as specifying euler is the only way
> to make gnucap ignore the error (and if ignoring the error
> is desirable somehow). i was assuming that "choice of
> integration method" and "truncation error handling" are
> different topics. i think they should be, see below.

To most users there are too many options.

The method and step control really are related.

Step control is not just truncation error.

If the calculation of truncation error really was strictly 
mathematically correct, it might seem you would always want to 
use "trap", because when error is small it is always less then 
Gear or Euler.

The problem is that it would lead to tiny steps that are not 
really needed.

Recall .. Gear and Trap are second order methods.  Error is 
proportional to some h^2.  When h is small, h^2 is smaller.  
When h is big h^2 is bigger.

On the surface we only care about h small.  But really that is 
not so.  There are times when we want to allow a large time step 
and HIDE the error with the intent of ignoring it.

So we pick a method that presents its error in a manner suitable 
to be ignored even though it is large.  That's Backward Euler.  
The error will always be such that the impulse response decays 
out faster than the real impulse repsonse.  When the real 
impulse response decays so fast I can ignore it, the way 
Backward Euler presents its error is exactly what I want.

If Euler is used with truncation error checking, its error will 
always dominate, and force time stepping much smaller than 
appropriate.


> Gnucap   System status
> iterations: op=0, dc=0, tran=4053, fourier=0, total=5405
> transient timesteps: accepted=1169, rejected=183, total=1352.
> 
> with .options method=euler (per device method selection does
> not seem to be implemented) i get
> 
> Gnucap   System status
> iterations: op=0, dc=0, tran=854, fourier=0, total=1139
> transient timesteps: accepted=256, rejected=29, total=285,
> 
> which is effectively due to ignoring the error in c1.

Per device method selection is partly implemented.  I thought it 
was working at one time, but got removed?  Two lines of code 
would put it back in the simple devices. (parse and print).

Actually that was the intent, so you could mark the devices you 
don't care about, or indicate in the model source for complex 
models.

The more important place was in devices generated by modelgen, 
so the strays can be there for model completeness, but only 
really matter sometimes.

Probably what happened was that I was working on it and got 
called away and never got back to it.

> now, what i have tried to work out is an adaptive method
> selection. in the pulse & lowpass example, the pulse source
> introduces discontinuities in the node voltages that break
> trap in an obvious way. it totally makes sense to switch
> back to euler in c1 (only) for those steps succeeding the
> discontinuities -- *without* turning off step control...

Interesting ..  

I see they all have a high number of rejections.  Please try 
again after applying the pulse patch.  I think your results are 
contaminated by pulse time step issues.

I tried some things like that long ago, and eventually gave up 
and took a different path.

The different path was to add another step control based on 
curve fitting, that is used when truncation error is 
meaningless.