[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnucap] Convergence error
From: |
al davis |
Subject: |
Re: [Help-gnucap] Convergence error |
Date: |
Fri, 19 May 2006 13:31:47 -0400 |
User-agent: |
KMail/1.9.1 |
On Friday 19 May 2006 08:41, Jose Roberto B. de A. Monteiro
wrote:
> I have a convergence error im my simulation. Basically, I
> have to work with switchmode circuits. I am trying to build
> a simple sawtooth generator using a current source, a
> capacitor and a voltage controled switch, with a non-zero
> RON.
>
> The circuit is like the following:
>
> * circ-3
> * Spice netlister for gnetlist
> SW1 1 0 1 0 SWITCH1
> C1 1 0 1n
> I1 0 1 100u
> .model npn npn
> .MODEL SWITCH1 SW VT=2.5 VH=2.475 RON=1 ROFF=10MEG
> .print tran V(C1)
> .tran 0 200e-6 500e-9 UIC >circ-3.dat
> .END
There is a bug in the switch model. I have known about a
convergence problem for a long time, but this circuit
demonstrates it perfectly, so I found the bug quickly. Thank
you!
I assume you compiled it yourself, so make this change:
diff -u -r25.77 d_switch.cc
--- d_switch.cc 2006/04/23 22:18:03 25.77
+++ d_switch.cc 2006/05/19 15:28:40
@@ -262,7 +262,8 @@
}else if (_y0.x < m->vt - m->vh) {
new_state = _OFF;
}else{
- new_state = _previous_state;
+ //new_state = _previous_state;
+ new_state = _current_state;
}}
{if (new_state != _current_state) {
address@hidden:/home/al/gnucap/src>
or ...
In the file "d_switch.cc" change line 265 ..
from:
new_state = _previous_state;
to:
new_state = _current_state;
The bug shows when a switch with hysteresis changes state inside
a feedback loop, and the new state is inside the hysteresis
region.
What was happening is that instead of keeping the new state,
from the previous iteration, it reverted to the previous time
step. Of course this is wrong, it just changed state, so it
changes again. This results in alternating samples which will
never converge. Since it is a hard switch, making the time
step smaller won't help, and Newton damping won't help.
=====================
Now, to take the opportunity to give a little lesson........
You can see what is happening, every iteration, by adding "trace
iterations" to the transient command.
You can see the state of the switch by probing "R(SW1)". This
will show the actual resistance being used. Looking at every
iteration, it shows that it was alternating between the on and
off values.
I played with damping (dampmax, dampmin, dampstrategy options)
and found that the result was convergence to nonsense,
indicating a more serious problem. If the cause of
nonconvergence is an artifact of Newton's method behaving
exactly as it is known to behave, this will usually fix it.
Now to explain the message ,,,,
> very backward time step
Gnucap can move backwards in time, a little bit. It tried and
found it was not enough, then tried some more. It needed to
move backwards more than what is stored.
> convergence failure (itl4)
The reason for moving backwards is a convergence failure,
relating to the option "itl4". It could not converge in itl4
iterations.
> newtime=4.987417e-05
The suggested time to try.
> rejectedtime=4.987417e-05
The time that didn't work.
> oldtime=4.987417e-05
The last time that did work.
> using=4.987417e-05
An adjusted suggestion for time to try.
> zero time step
The difference between these times is essentially zero.
Actually ...
> newtime=4.987417e-05
> rejectedtime=4.987417e-05
> oldtime=4.987417e-05
This is redundant. I should fix it to only print these numbers
once.
We have some revised parameters. Let's try again for a last
attempt to get something....
> internal error: step control
Sorry, I give up...
> (adt=1e-12
Actual dt. It took this time step.
time0 - time1
> rdt=-5.36442e-13)
But this is the one that was needed.
(notice .. it's negative)
rtime - time1
> time0=4.98742e-05
Time it actually used
> time1=4.98742e-05
Time at the previous step
> rtime=4.98742e-05
Time it should have used.
It is trying to reject a previously accepted time step, and not
succeeding, because the code for that is incomplete.
It wouldn't have helped anyway.
> Maybe because I am not using the lastest GNUCAP.
You are not, but that is not the problem.
I will try to get the patched version out soon. For now, change
that line and recompile.