#505 non-deterministic behaviour of DC transient solution (fcn limit)

[Ferdy]

This is a follow-up of discussion https://sourceforge.net/p/ngspice/discussion/127605/thread/7ba9a548d7/

NGspice 32 shows a non-deterministic behaviour of its DC transient solution, even with a simple circuit. The algorithm fails to find a solution about 25% of the times I run it. If compiled with STEPDEBUG enabled, and one can see that the results start to diverge after the message 'limited by pre-breakpoint delta' is printed, see attachment.

To reproduce this issue, build ngspice 32 from git master branch, and call several times:
./src/ngspice -b -r Vsetpoint.raw Vsetpoint.cir | grep unrecorded

Thanks in advance.

[Justin Fisher]

What happens if you put a really high-value resistor in parallel with C4?
Or maybe put an initial condition on Vref Net-C4-Pad1 ?

--
Kind regards,

Justin Fisher.

[Ferdy]

Thanks for the hints. I have tried both options you suggested, but still get the same error.

I have also tried removing R4 and C4 completely from the netlist, but it still fails about 25% of the times.

I have also added on C2 and C6 a big resistor in parallel, but it still fails.

If I remove from the circuit either C2, or "c5 and c6", then it works fine. But why should it be non-deterministic otherwise?

[Holger Vogt]

Could you please check ngspice from the pre-master branch? That is the actual development branch. There has been removed at least one memory corruption error.

[Ferdy]

I just tried with the pre-master branch. Similar issue.

One thing I have noticed (in both versions) is that the non-deterministic problem might come from the use of the subcircuit (Potentiometer.lib).

If I replace:

R0 1 2 {Rtot*(1-w)}
R1 2 3 {Rtot*(w)}

with

R0 1 2 5k
R1 2 3 5k

the simulation always runs well.

However, I do not see why this subcircuit with the parameters should be wrong; it appears in several examples online, https://electronics.stackexchange.com/a/229548 https://bugs.launchpad.net/kicad/+bug/1766931

Maybe something is not being initalized correctly for Rtot, or w?

[Ferdy]

I think I found out why it is failing. Apparently, ngspice does not cope well the function 'limit'. What I do not understand is why it does not give a warning saying 'function not recognized, or incorrect signature, or something like that.

So, if one adds this to the subcircuit, it works fine:
.func limit(x, y, z) {min(max(x, min(y, z)), max(z, y))}
(https://sourceforge.net/p/ngspice/discussion/133842/thread/5ab13322/)

I found out by enabling ngdebug, where I could see that the expression evaluator was interpreting that the potentiometer has negative resistances, because the 'limit' function was interpreted somehow randomly.

**************** uncommented deck **************

 1       1  Vsetpoint
 3      34  r4 vref net-_c4-pad1_ 3
 4      35  c4 net-_c4-pad1_ 0 2.2u
 5      36  r2 vpot vref 5k
 6      37  r3 0 vdrain 333
 7      38  c2 vpot 0 10u
 8      39  c5 vset 0 0.1u
 9      40  c6 vset 0 1n
10      41  v1 vref 0 dc 0 pulse(0 2.5 5m 3m 3m 200m 1)
 0      29  r.xrv1.r0 vpot vset  -5.00000000000000000e+03 
 0      31  r.xrv1.r1 vset vdrain  -5.00000000000000000e+03 
27      58  .tran 1m 300m
31      60  .end

[marcel hendrix]

In ngspice-32, limit is defined as

new_str = copy(".func limit(x, a, b) { min(max(x, a), b) }");

There was a reason for the difference.

The limit function is not in the KLU branch and I seem to have hard-coded it:

.SUBCKT POT 1   2   3 wiper=0.5 Rtot=1k
*.param w=limit(wiper, 0, 1)
R0 1 2 { Rtot * (1-wiper) }
R1 2 3 { Rtot * (wiper) }
.ENDS POT

I did not expect the problem to be in limit(), so I didn't even think about mentioning
it. Anyway, even with a different limit() function non-determinism should not happen.

-marcel

[Ferdy]

Thanks.

Concerning non-determinism, clang reports some uninitialized values in the code that might be the source of error, see full report here:
https://sourceforge.net/p/ngspice/bugs/502/#d398

Bug Group   Bug Type ▾  File    Function/Method     Line    Path Length     
Logic error Uninitialized argument value    frontend/inpcom.c   get_number_terminals    4144    50  View Report
Logic error Uninitialized argument value    spicelib/devices/hisimhv2/hsmhv2noi.c   HSMHV2noise 237 34  View Report
Logic error Uninitialized argument value    spicelib/devices/hisimhv1/hsmhvnoi.c    HSMHVnoise  195 33  View Report
Logic error Uninitialized argument value    spicelib/analysis/cktterr.c CKTterr 69  20  View Report

[marcel hendrix]

On 2020-08-16 19:36, Ferdy wrote:

Thanks.

Concerning non-determinism, clang reports some uninitialized values in
the code that might be the source of error, see full report here:
https://sourceforge.net/p/ngspice/bugs/502/#d398

There is also Occam's razor :-)

Things will become much more interesting as soon as an example is
provided that can be independently verified.

-marcel

[Francesco Lannutti]

This is the typical bug which generates non-determinism.
On Linux, just run your simulation with Valgrind to see that.

The other typical root cause is ordering by pointers, but I don’t think NGSPICE makes usage of it.

Fra

Il giorno 16 ago 2020, alle ore 20:11, marcel hendrix mhx_at_sf@users.sourceforge.net ha scritto:

On 2020-08-16 19:36, Ferdy wrote:

Thanks.

Concerning non-determinism, clang reports some uninitialized values in
the code that might be the source of error, see full report here:
https://sourceforge.net/p/ngspice/bugs/502/#d398

There is also Occam's razor :-)

Things will become much more interesting as soon as an example is
provided that can be independently verified.

-marcel

---

** [bugs:#505] non-deterministic behaviour of DC transient solution**

Status: open
Group: v1.0 (example)
Created: Mon Aug 03, 2020 11:17 AM UTC by Ferdy
Last Updated: Sun Aug 16, 2020 05:36 PM UTC
Owner: nobody
Attachments:

• Potentiometer.lib (sourceforge.net) (490 Bytes; application/octet-stream)
• Screenshot at 2020-08-03 12-56-00.png (sourceforge.net) (120.3 kB; image/png)
• Vsetpoint.cir (sourceforge.net) (464 Bytes; application/octet-stream)

This is a follow-up of discussion https://sourceforge.net/p/ngspice/discussion/127605/thread/7ba9a548d7/

NGspice 32 shows a non-deterministic behaviour of its DC transient solution, even with a simple circuit. The algorithm fails to find a solution about 25% of the times I run it. If compiled with STEPDEBUG enabled, and one can see that the results start to diverge after the message 'limited by pre-breakpoint delta' is printed, see attachment.

To reproduce this issue, build ngspice 32 from git master branch, and call several times:
./src/ngspice -b -r Vsetpoint.raw Vsetpoint.cir | grep unrecorded

Thanks in advance.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ngspice/bugs/505/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Holger Vogt]

Valggrind does not show anything (except for a memory leak when the tran simulation is aborted).

But doing a 'listing e', if run interactively, you may get

ngspice 258 -> listing e
        Vsetpoint

     1 : vsetpoint
    34 : r4 vref net-_c4-pad1_ 3
    35 : c4 net-_c4-pad1_ 0 2.2u
    36 : r2 vpot vref 5k
    37 : r3 0 vdrain 333
    38 : c2 vpot 0 10u
    39 : c5 vset 0 0.1u
    40 : c6 vset 0 1n
    41 : v1 vref 0 dc 0 pulse(0 2.5 5m 3m 3m 200m 1)
    29 : r.xrv1.r0 vpot vset  -1.00000000000000085e+02 
    31 : r.xrv1.r1 vset vdrain  -9.90000000000000000e+03 
    58 : .tran 1m 300m
     0 : .options sparse
    45 : .end

Negative resistance, sometimes so (and crashing tran), sometimes

     3 : r.xrv1.r0 vpot vset   1.99000000000000000e+04 
     4 : r.xrv1.r1 vset vdrain  -9.90000000000000000e+03 

and not crashing.

The root cause is the 'limit' function in line 20 of Potentiometer.lib. We had problems with it already in other places.

It is a problem of compatibility of different 'limit' functions (spice3, ngspice, PSPICE, HSPICE). I will look into this.

[marcel hendrix]

On 2020-08-16 19:36, Ferdy wrote:

Thanks.

Concerning non-determinism, clang reports some uninitialized values in
the code that might be the source of error, see full report here:
https://sourceforge.net/p/ngspice/bugs/502/#d398

I thought we decided that the perceived problem roots in an incorrect
definition of the build-in 'limit' function.

(Of course) we can't prove that NGSPICE always behaves
deterministically.

If we look at the presented case, we might attempt to state that even
a wrongly defined LIMIT function should still result in NGSPICE doing
the same thing every time. The idea then is that when f is defined
as '3x^2 - 5' instead of '2x^2 - 5' we find different roots for f, but
they are still the same for every run.
However, I think that there should be a restriction here: the
alternative
computation should be well-defined.

In the present case the wrong limit causes negative resistance. As a
result the Vpot goes to infinity around 7ms. So my proposal is to check
values only before that point. When we do that, there is no evidence
of non-determinism.

.title Vsetpoint

.include Potentiometer.lib

R4 Vref Net-_C4-Pad1_ 3
C4 Net-_C4-Pad1_ 0 2.2u
R2 Vpot Vref 5k
R3 0 Vdrain 333
C2 Vpot 0 10u
C5 Vset 0 0.1u
C6 Vset 0 1n
V1 Vref 0 dc 0 pulse(0 2.5 5m 3m 3m 200m 1)
XRV1 Vpot Vset Vdrain POT Rtot=10k wiper=0.01

.control
    repeat 100
      reset
      tran 1m 7m 0 1m    $ note 7 ms < blowup point
      let a = time[15]
      let b = vpot[15]
      echo time[15]=$&a  vpot[15]=$&b
    end
    quit
.endc

.end

If we run this file with ngspice 32:

D:\spice\mhx\bug_deterministic>spice64w Vsetpoint.cir | grep time\[15\]

the result is

Warning: no graphics interface!
  You may use command 'gnuplot'
  if GnuPlot is installed.
time[15]=0.0044336 vpot[15]=000
time[15]=0.0044336 vpot[15]=0
... ( same result deleted )
time[15]=0.0044336 vpot[15]=0
time[15]=0.0044336 vpot[15]=0

D:\spice\mhx\bug_deterministic>

-marcel

[Francesco Lannutti]

Valgrind should show the unconditional jump due to uninitialized value.

Fra

Il giorno 17 ago 2020, alle ore 11:25, marcel hendrix mhx_at_sf@users.sourceforge.net ha scritto:

On 2020-08-16 19:36, Ferdy wrote:

Thanks.

Concerning non-determinism, clang reports some uninitialized values in
the code that might be the source of error, see full report here:
https://sourceforge.net/p/ngspice/bugs/502/#d398

I thought we decided that the perceived problem roots in an incorrect
definition of the build-in 'limit' function.

(Of course) we can't prove that NGSPICE always behaves
deterministically.

If we look at the presented case, we might attempt to state that even
a wrongly defined LIMIT function should still result in NGSPICE doing
the same thing every time. The idea then is that when f is defined
as '3x^2 - 5' instead of '2x^2 - 5' we find different roots for f, but
they are still the same for every run.
However, I think that there should be a restriction here: the
alternative
computation should be well-defined.

In the present case the wrong limit causes negative resistance. As a
result the Vpot goes to infinity around 7ms. So my proposal is to check
values only before that point. When we do that, there is no evidence
of non-determinism.

~~~
.title Vsetpoint

.include Potentiometer.lib

R4 Vref Net-C4-Pad1 3
C4 Net-C4-Pad1 0 2.2u
R2 Vpot Vref 5k
R3 0 Vdrain 333
C2 Vpot 0 10u
C5 Vset 0 0.1u
C6 Vset 0 1n
V1 Vref 0 dc 0 pulse(0 2.5 5m 3m 3m 200m 1)
XRV1 Vpot Vset Vdrain POT Rtot=10k wiper=0.01

.control
repeat 100
reset
tran 1m 7m 0 1m $ note 7 ms < blowup point
let a = time[15]
let b = vpot[15]
echo time[15]=$&a vpot[15]=$&b
end
quit
.endc

.end
~~~

If we run this file with ngspice 32:

~~~
D:\spice\mhx\bug_deterministic>spice64w Vsetpoint.cir | grep time[15]
~~~

the result is

~~~
Warning: no graphics interface!
You may use command 'gnuplot'
if GnuPlot is installed.
time[15]=0.0044336 vpot[15]=000
time[15]=0.0044336 vpot[15]=0
... ( same result deleted )
time[15]=0.0044336 vpot[15]=0
time[15]=0.0044336 vpot[15]=0

D:\spice\mhx\bug_deterministic>
~~~

-marcel

---

** [bugs:#505] non-deterministic behaviour of DC transient solution**

Status: open
Group: v1.0 (example)
Created: Mon Aug 03, 2020 11:17 AM UTC by Ferdy
Last Updated: Mon Aug 17, 2020 08:17 AM UTC
Owner: nobody
Attachments:

• Potentiometer.lib (sourceforge.net) (490 Bytes; application/octet-stream)
• Screenshot at 2020-08-03 12-56-00.png (sourceforge.net) (120.3 kB; image/png)
• Vsetpoint.cir (sourceforge.net) (464 Bytes; application/octet-stream)

This is a follow-up of discussion https://sourceforge.net/p/ngspice/discussion/127605/thread/7ba9a548d7/

NGspice 32 shows a non-deterministic behaviour of its DC transient solution, even with a simple circuit. The algorithm fails to find a solution about 25% of the times I run it. If compiled with STEPDEBUG enabled, and one can see that the results start to diverge after the message 'limited by pre-breakpoint delta' is printed, see attachment.

To reproduce this issue, build ngspice 32 from git master branch, and call several times:
./src/ngspice -b -r Vsetpoint.raw Vsetpoint.cir | grep unrecorded

Thanks in advance.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ngspice/bugs/505/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Holger Vogt]

The standard limit function in ngspice is a HSPICE statistical function and is resolved to

static double
limit(double nominal_val, double abs_variation)
{
    return (nominal_val + (drand() > 0 ? abs_variation : -1. * abs_variation));
}

and is using random numbers! So we get a strange "non-reproducibility".

Only when PSPICE compatibility is enabled, we have the limit function

.func limit(x, a, b) { min(max(x, a), b) }

I will have to find a meaure to separate the two functions, maybe based on the count of their parameters.