Re: [Gnucap-devel] user input to a running simulation

[Felix Salfelder]

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