[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] bug in pulse
From: |
al davis |
Subject: |
Re: [Gnucap-devel] bug in pulse |
Date: |
Fri, 29 Nov 2013 19:57:26 -0500 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
On Wednesday 27 November 2013, Felix Salfelder wrote:
> if the rise time is 0, the pulse value at _delay is wrong.
.....
> the pulse is evaluated to 1 at time=.1. i think this is wrong
> because for any positive value of delay it is (should be)
> zero, and delay=0 should actually be treated as
> delay=epsilon with epsilon a positive number somewhere
> between 0 and dtmin (if not just the limit -> +0).
>
> the example above shows that _iv is required at _delay, as
> the first event is interpreted as pre-rise by the solver
> (see output below).
>
> i'm a bit unsure on how to fix this. also fwiw, there is a
> discrepancy between the manual.pdf and the implementation
> wrt to ">" vs ">=" in tr_eval, lines "if (time >=
> _delay+_rise+_width+_fall) {".
>
> any clues?
It's not a bug, it's a feature! :-)
The purpose of "pulse" is spice compatibility, and so it is,
bug-for-bug.
The documentation is obsolete.
In 2007, RCS 26.55 2007/12/05 it was changed for Spice
compatibility.
In the older code, the interpretation of delay when period was
specified was also different from what Spice did.
Having said that, I agree with you on what behavior makes sense,
which is why it was that way originally when I did what I
thought made sense as opposed to studying the nuances of spice
code.
Then I wondered why there are so many rejections with your
example. There is only one rejection when the code is changed
to the old way.
After a bit of puzzling and testing, that too becomes clear.
It's based on truncation error. The state change seems wrong,
so back off and try again with smaller steps. It keeps getting
smaller and smaller.
Time v(1) v(2) next(c1)
0.09999999955 0. 0. 0.
0.1 0.9999900001 223.044p 0.09999999975
0.1000000002 0.9999900001 443.042p 0.1000000006
So, although it looks like a problem, it is working as designed.
You can get the behavior you want by changing ">=" to ">". If
you do you must change all of them in that function.