gnucap-devel
[Top][All Lists]
Advanced

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

[Gnucap-devel] user input to a running simulation


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

Hello,

I'm trying to create some simple mechanism to enable user-driven input
to a running simulation. I'd like to achieve something like quasi
real-time transient simulation with occasional user input. This can be
described like this:

loop forever
{
  if (user input available)
  {
    get user input
    alter something in schematics if necessary
     (usually a value of some non-storage element like R, V or I, but
      sometimes it may be needed to alter a connection)
  }
  run transient for next time step, e.q. 50ms
  get results from simulation
  show results (scrolling plot and drawing new results at the end)
  wait 0--50ms for next time slot, synchronization with "wall clock"
}

For each transient run I want reasonably accurate results from last step
(at final time) but I don't need the intermediate values.

I like it that with gnucap there is a way to continue transient
simulation. However after 'MODIFY/ALTER' the simulation is reset and all
initial conditions are determined by something like IC analysis and I'd
like it to continue.

I managed to hack gnucap a little (can send a preliminary patch against
2009-12-07 if anybody is interested) and it's somewhat promising, but
I'm not a C++ expert and I think there is a much better way to
accomplish this. For example:

given the simple condensator charging/discharging circuit - charging for
2 seconds to 5V then discharging to 1V for the next 2 seconds
====================
Testing resume of TRAN after ALTER

V1 1 0 DC 5V
R1 1 2 40k
C1 2 0 10u

.print tran v(1) v(2)
.tran 0 1 1e-1 uic
.tran

.alter V1=1
.tran
.tran
====================

I get:

--------------------
#Time       v(1)       v(2)
 0.         0.         0.
 0.1        5.         1.1074
 0.2        5.         1.9725
 0.3        5.         2.6452
 0.4        5.         3.1685
 0.5        5.         3.5755
 0.6        5.         3.8921
 0.7        5.         4.1383
 0.8        5.         4.3298
 0.9        5.         4.4787
 1.         5.         4.5946    *
#Time       v(1)       v(2)       * continuous
 1.         5.         4.5946    *
 1.1        5.         4.6846
 1.2        5.         4.7547
 1.3        5.         4.8092
 1.4        5.         4.8516
 1.5        5.         4.8846
 1.6        5.         4.9102
 1.7        5.         4.9302
 1.8        5.         4.9457
 1.9        5.         4.9578
 2.         5.         4.9672    *  (at t=2 the change appears)
#Time       v(1)       v(2)       * v(2) is discontinuous
 2.         1.         4.5227    *
 2.1        1.         3.7438
 2.2        1.         3.134
 2.3        1.         2.6598
 2.4        1.         2.291
 2.5        1.         2.0041
 2.6        1.         1.781
 2.7        1.         1.6074
 2.8        1.         1.4724
 2.9        1.         1.3674
 3.         1.         1.2858    *
#Time       v(1)       v(2)       * continuous
 3.         1.         1.2858    *
 3.1        1.         1.2223
 3.2        1.         1.1729
 3.3        1.         1.1345
 3.4        1.         1.1046
 3.5        1.         1.0813
 3.6        1.         1.0633
 3.7        1.         1.0492
 3.8        1.         1.0383
 3.9        1.         1.0298
 4.         1.         1.0232
--------------------

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).

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.

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?


Best regards,
Pawel



reply via email to

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