Re: gEDA-user: very backward time step?

[al davis <ad252@xxxxxxxxxxxxxxxx>]

On Friday 17 September 2010, Chris Cole wrote:
> I'm trying to do a very simple power supply simulation with
> gschem and  I'm not getting very far.
> I'm trying to do a bridge rectification of a 24 VAC supply to
> DC  current. I'm able to do a transient analysis for 10
> iterations before I get:
> 
> very backward time step
> convergence failure, reducing (itl4)
> 
> I read somewhere that "very backward time step" is indicative
> of a  software bug. I'm sending my example schematic and
> netlist and a sample script, sim.sh that I'm using to run
> everything.

As usual, John Doty is wrong.

You should get a more recent version of gnucap.

With 0.35, I had to make gmin=100u.
With the latest, it worked fine as is.

Gnucap time step control is usually more robust than Spice, 
especially with recent development snapshots, although sometimes 
Spice appears to work but gives wrong answers without warning, 
and on the same circuit Gnucap honestly admits failure.

If I run from the .net file, and manually do the rest, it works 
fine for me, but add "trace all" to the transient command so you 
get all of the time steps.

If I run from your .sh script, gnetlist clobbers the .net file, 
and the generated .net file has some problems .. no ground, a 
missing value ...  That script doesn't work with recent 
snapshots, you must be using an old version.

If you are simulating power supplies, remember that the defaults 
for things like GMIN are designed for small CMOS circuits, so 
you might need to change them.

Your time step parameters (specified in Fortran order, not spice 
order, that's ok) don't make sense for this circuit.  Showing a 
visible step size of .1 second will hide most of the info for a 
60 Hz input.  Assuming you want to hide that and look at the 
ringing of the LC filter, it's still too coarse.

Recent versions of gnucap will figure out proper internal time 
stepping ok in spite of that error, but just show you samples at 
.1 second.  Older versions may need some help to make sure the 
60 Hz signal is accomodated with a .1 second visible step.  This 
might be the problem you are seeing.  If that is the case (and 
you are using an old version of gnucap) try adding the option 
"skip 100" to the transient command, which will force an 
internal time step 100x smaller than the printed time step.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user