help-gnucap
[Top][All Lists]
Advanced

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

Re: [Help-gnucap] Convergence Failure


From: al davis
Subject: Re: [Help-gnucap] Convergence Failure
Date: Thu, 9 Aug 2007 01:57:36 -0400
User-agent: KMail/1.9.7

On Sunday 05 August 2007, Crispy wrote:
> Hello,
>
> I'm trying to make a simulation of a Tesla coil circuit with
> an interesting type of spark gap, but am having trouble. 
> Currently many of the components don't have exact values or
> are approximations for real behavior, but I can fix that as
> soon as I have the basic simulation running. 

I made it work by adding parallel conductance to the diode.

.MODEL DHV         D(BV=25000 gparallel=1e-6)

Sometimes making it too ideal is the problem.  Convergence 
problems usually indicate that your circuit doesn't work, but 
it is not clear just how it doesn't work.

Convergence problems during a transient analysis (after a 
successful initial solution) often indicate a "bifurcation", an 
unstable point.  What you probably want is for the solution to 
snap from one value to another.  The simulator tries to get a 
reasonable result in the unstable region, and fails.  The 
solution to the problem is to use values closer to the real 
ones, including capacitance and inductance.

Another apparent problem here is that some nodes can go 
completely open.  Consider two capacitors in series.  What is 
the DC voltage at their junction?  It is impossible to know.  
Now add some leakage and it is solvable.  You can get a similar 
problem with a bridge rectifier.  At some point, all diodes are 
open.  Give it some leakage.

> storage element step control error:Ldbl 5.47113e-13
> using Euler, disabling time step control
> very backward time step
> convergence failure, reducing (itl4)
> newtime=5.208333e-03  rejectedtime=5.208333e-03 
> oldtime=5.208333e-03 using=5.208333e-03
> tried everything, still doesn't work, giving up

To see what this really means, you also need to see when it 
occurs.  When I ran it, there were also "open circuit" 
warnings.

Let's pick it apart ....

> storage element step control error:Ldbl 5.47113e-13

Something happened to suddenly change things.  Maybe a sudden 
change of current.  Back up ... try smaller time steps ... 
enough smaller that it is no longer "sudden".

Perhaps that sudden change is a switch changing from 1e9 to 100 
ohms, with a sudden 1e7 change in time constant, which leads to 
a 1e7 change in step size.

The usual formula, based on truncation error, gives a time step 
way too small.  (based on option dtmin)

so ....

> using Euler, disabling time step control

Use Euler's method instead of the usual trapezoidal (Huen's)  
method.   "Ldbl" no longer influences time stepping.  Other 
components still work the usual way.  "Ldbl" is not removed 
from the circuit.  It is just solved in a way that the error is 
in a favorable direction.

Try to keep running ...  

After a while ....

> very backward time step

This is equivalent to the Spice "time step reduced to zero", 
except that it tries to solve the problem by moving backwards, 
and fails.

Here's why it failed:

> convergence failure, reducing (itl4)

It failed to converge, based on the number "ITL4".

Hint: It might work if you increase ITL4.  It also might not.

> newtime=5.208333e-03  rejectedtime=5.208333e-03 
> oldtime=5.208333e-03 using=5.208333e-03
> tried everything, still doesn't work, giving up

All those times look the same, but they are not.  You can see 
what time it was at when it gave up.




To see what is happening, run it interactively...

You can add options to the tran command ...
"trace all" -- show every accepted time step
"trace rejected" -- also show the rejected ones
"trace iterations" -- show every iteration

This can provide more insight into what is happening.

In this case, the probes you chose don't show anything.  There 
is a problem somewhere you are not looking.  Try probing the 
diodes (i(d*.x*) .. the current,   v(d*.x*) .. voltage) might 
show.  You can really see what is happening by probing internal 
values (y(d*.x*) .. the incremental admittance).

By probing around, eventually the problem will show, and give 
you ideas of what to change.


I tried it on Spice.  It failed there too, with less 
information, and no way to go inside.

I also noticed that one of your sources is at 80 Hz instead of 
60.  It's probably a typo.








reply via email to

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