gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pawel Ludwikow
Subject: Re: [Gnucap-devel] user input to a running simulation
Date: Wed, 18 Apr 2012 08:45:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]