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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
