Re: user input to a running simulation

Pawel Ludwikow <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.