On Wednesday 18 April 2012, Pawel Ludwikow wrote: > Thanks for the idea. It works even on vanilla gnuspice.
gnucap is not spice ... > However to my surprise it produces exactly the same data as > my hack: > > -----[part] > 2. 5. 4.9672 > #Time v(1) v(2) > 2. 1. 4.5227 > -----[part] > > so it looks that my hack hasn't introduced this behavior. What happens here is that the values at the start time are recalculated using the new value. Remember .. in transient analysis, nothing can change instantaneously. The best you can do is to have it ramp from the old value to the new value within one time step, and time steps are variable. In this case, the previous time step is one-back from the previous run, or 1.9 seconds. So, v(1) is 5 at 1.9 and now 1 at 2.0. The voltage v(2) reflects that, so by 2.0 seconds it is already starting to go down. Since changes like this do not have proper time step control, you get different results with different "integration" methods. All are equally correct (or incorrect) because the actual waveform between points is unknown. Probably the best way to do what you want is to write a new "bm" plugin, where tr_eval would get a new value from outside. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
