Re: [Gnucap-devel] discontinuities

[Felix Salfelder]

On Wed, Jan 15, 2014 at 08:17:01PM -0500, al davis wrote:
> I ran the test case with my pulse patch, which has even better results.
> This is vanilla gnucap plus the pulse patch.
> 
> #Time       v(n1)      v(n2)      i(r1)      method(c1) control(0)
>  0.         0.         0.         0.         2.         1.        
>  0.1        0.         0.         0.         2.         9.        
> ...
>  0.5        0.         0.         0.         2.         6.        
>  1.         0.         0.         0.         2.         7.        
>  1.         5.u        4.995n     4.995n     2.         7.        
>  1.001      0.99998    0.98038    19.603u    2.         7.        
>  1.001      1.         0.98042    19.579u    2.         7.        
>  1.0011     1.         1.0145    -14.538u    2.         16.       
>  1.0012     1.         0.99008    9.9183u    2.         6.        
>  1.0013     1.         1.0054    -5.4414u    2.         6.        
>  1.0014     1.         0.99701    2.9853u    2.         6.        

this is surprising. particulatly because the pulse patch was about zero
rise time... anyway i(r1) looks pretty wrong to me and the ringing in v(n2)
is clearly a trap artifact.

> Having said that ..  I like the work you are doing with euler
> fallback.  You are fulfilling what I was thinking of when I created
> the "trapeuler" and "trapgear" stubs.

yes, maybe euler should continue to disable step control while trapeuler
may still fallback to a step-control-enabled euler. but lets postpone
these details -- currently i am failing to implement my algorithm
cleanly. i could need some input on the following.

imo it doesn't make sense to mess with integration methods globally if a
discontinuity occurs. so i decided to store discontinuities locally
(i.e. in nodes) and propagate through devices only if that seems
necessary.

my first attempt was roughly this one
- (clear all discontinuities before accept)
- tr_accept registers discontinuity in node (e.g. pulse, last step
  before rise etc.)
- tr_needs_eval returns true if an adjacent node (an input node?)
  voltage is discontinuous.
- tr_eval propagates discontinuity (e.g. d_res) or sets method
  acccording to what nodes say (e_storage).

this appears suboptimal. for example tr_needs_eval does not know about
propagated discontinuities... also, calling D_RES::tr_eval on a constant
resistor is asking for trouble (is this worth changing?).

then i have done something different (using tr_advance & regress). i
thought it might make sense to only propagate in tr_regress, since an
accepted step is good enough. now, examples prove me wrong...

any thoughts, good ideas?

regards
felix