Re: [Help-gnucap] Re: Scientific/engineering notation

[a r]

Adding second order methods to Gnucap is beyond my capability. I've
been trying this a while ago and gave up pretty soon.

As for the backward Euler method, doesn't it give overoptimistic
results for inherently unstable circuits? In my circuits I usually
have lot of passive devices modeling interconnections and I do want to
see any real ringing that may occur in the circuit.

I couldn't find any option for tightening accuracy. The only one I saw
was 'roundofftol', are there any other? For IC design simulations it
is common to decrease absolute tolerances for currents. BTW, does
Gnucap attempt to verify Kirchhoff's laws prior to accepting the
timestep result (as Spectre does)?

-r.

On Nov 30, 2007 2:59 AM, al davis <address@hidden> wrote:
> On Thursday 29 November 2007, a r wrote:
> > OK, I've found the solution:
> >
> > .probe tran v(in) v(n1) v(out)
> >
> > .dc
> > .tran 1n 4u >out.dat
> >
> > Looks like .probe and .print commands work same in this
> > context. Before I was trying to redirect the .print's output
> > to the file instead of redirecting the analysis (.tran)
> > itself.
>
> They are the same.  There is a historical reason for it.  It was
> originally "probe" only, then "print" was added for "spice
> compatibility".
>
> At that time, the "spice compatibility" goal meant that it would
> be possible to make files that worked in both.  It was never
> intended for gnucap to be like a spice clone.  There are
> features of the gnucap way that I cannot give up.
>
> > BTW, I am getting pretty strong numerical ringing in this
> > analysis. AFAIK, gear method is not yet implemented. Any
> > chance for this?
>
> For now, try "method=euler".
>
> The Gear method is almost never the best choice.  It is popular
> because it is often the second choice.  If trap is giving you
> trouble and Gear would fix it, Euler would be more accurate.
> If Euler is not accurate enough and Gear is better, trap is
> even better.
>
> Specifying Euler disables the truncation error part of time step
> control.  This is what you want.
>
> If you really want it to be accurate, tighten the tolerances to
> make it stop ringing.
>
> It may seem counterintutive that a first order method would be
> more accurate than a second order method, but in this case,
> it's true.
>
> Consider this:
>
> First order means error is proportional to something quantity I
> will call "h".
>
> Second order means error is proportional to h^2.
>
> Which one is smaller depends on the value of h.  People think
> the higher order method is more accurate because when h is
> small, h^2 is even smaller.  They forget that when h is large,
> h^2 is larger.   For accurate simulation, h is small.  When you
> see trapzoidal ringing, h is large.  The actual error with
> Gear's method is higher than trap (more correctly "Huen's
> method"), but it is in a form that is less apparent.
>
> If you want reasonable results with a time step that is too
> large for the time constant, use Euler.  This is a reasonable
> request.  Strays often are in this category, you would like to
> ignore them.  Euler errs reliably in the direction of ignoring
> them.
>
> As to any chance for adding the Gear method ,,,,  I have no
> objection to including it as an option, but I have other higher
> priorities for now.  If you (or anyone reading this) want to
> add it, and can show that it is correct, I will welcome the
> addition.
>
> It's not as simple as it seems.  It is harder in gnucap than in
> Spice, because time stepping in Spice is global.  All devices
> share the same set of time steps.  In gnucap, time stepping is
> local.  Different devices can have different time steps.
>
> The issue for Gear is computing the coefficients with unequal
> steps,  When stepping is uniform, you can look up the
> coefficients in a table,  It's easy.  When stepping is
> non-uniform, the coefficients must be calculated, possibly for
> every step, and since time history is local, for every device.
>
> If you forget about this, you may not see the error, because
> usually stepping is synchronous, and will hide the bug.  Then
> occasionally you get a spike of really strange results that
> can't be explained.
>
> One possibility I have considered is a Spectre-like "trap-gear"
> or "gear-euler" method, where it switches methods on the fly,
> using Gear when it is easy and switching to something else when
> it causes trouble.
>
> I'm getting technical here ......  It is because of these
> subtleties that I didn't do it already.
>
>
>
>
>
>
> _______________________________________________
> Help-gnucap mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gnucap
>