W dniu 17.04.2012 18:40, Felix Salfelder pisze: > On Tue, Apr 17, 2012 at 05:22:40PM +0200, Pawel Ludwikow wrote: >> and it seems that something happens I don't know about - the voltages at >> node 2 aren't equal after the change (node 1 is different, I explicitly >> asked it to be changed). > > what you can do as a workaround is this: > > .param b=5 [...]
Thanks for the idea. It works even on vanilla gnuspice. 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. > >> I think that the best solution would be: let the initial conditions of >> all elements for next simulation run be the final values for these >> elements from previous run, even after change. > > the initial conditions i.e. the charge on the cap should be unchanged > (relative to the last step of the previous tran) and not be your problem. My observation is that SIM_DATA::init() is called after ALTER and it resets the simulation to zero stage via CARD_LIST::card_list.tr_begin() I had to add some code because on the other side forcibly using only CARD_LIST::card_list.tr_restore() does not propagate the new value of the just changed element. >> Can you help me with this? I'd like to see this feature in gnuspice and >> I will try to do it, but can somebody knowledgeable point me in a right >> direction or perhaps invent a better way to accomplish this? > > calling tran with > .tran trace=v > might give some insight on whats going wrong for you. the problem seems > to be the initial step, which starts with the correct voltage, then does > something unexpected. if you manage to skip the first step somehow, it > might do what you want... I'll look into this. Best regards, Pawel Ludwikow _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
