On Sat, Apr 21, 2012 at 09:27:50PM -0400, al davis wrote: > 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.
if a bm is even necessary... here my reply that again got lost in the institutes mail transport (where i was wondering why Pawels simulation result is not continous): On Wed, Apr 18, 2012 at 08:45:27AM +0200, Pawel Ludwikow wrote: > -----[part] > 2. 5. 4.9672 > #Time v(1) v(2) > 2. 1. 4.5227 ^A ^B ^C for me, vanilla gnucap (2009.12.07 RCS 26.136) computes something continuous. here, A is 1, B is 5 and C continous. does the switch time and the delay parameter (which must be 2 for you!) coincide? > 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. yes. alter triggers re-expansion. param changes do not. > > .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... theres a problem with my proposal: if you just skip the first step, you will break timestep control. note that the pulse model sends events to the simuator enforcing a time step both at the begining and end of the transition. when a constant source is used (and removal of the 1st step works out) make sure your hack also adjusts the time for the 2nd step. have fun felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
