Re: [Help-gnucap] Convergence error

[al davis]

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.