#783 Alter command hangs forever on large netlist

[Chad Winters]

I have a netlist which is about 160,000 lines. Performing op analysis works fine. However, performing alter followed by op hangs forever.

You can find the problematic file in the link below labelled cct_bad. I am filing this as a bug since the circuit simulated successfully without alter.

Tested on ngspice-44.2 on Arch linux.

https://drive.google.com/file/d/1dDRBlHPpdnja-a68Lm3KmhOoaq0l-yds/view?usp=sharing

[Holger Vogt]

This is what I get with cct_bad.sp (git branch pre-master-45, VS2022, Windows 10, i9 9900):

spice.rc in User/user
******
** ngspice-44+ : Circuit level simulation program
** Compiled with KLU Direct Linear Solver
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Copyright 2001-2024, The ngspice team.
** Please get your ngspice manual from https://ngspice.sourceforge.io/docs.html
** Please file your bug-reports at http://ngspice.sourceforge.net/bugrep.html
** Creation Date: Tue Apr 29 09:53:06 UTC 2025
******
Start finished after 0.032 seconds.

Note: Compatibility modes selected: ps lt a


Circuit: ebana_circuit

Source Deck finished after 1.276 seconds.
Prepare Deck finished after 2.340 seconds.
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Parse finished after 3.231 seconds.
Using SPARSE 1.3 as Direct Linear Solver
Device Setup finished after 4.251 seconds.

No. of Data Rows : 1
v(n_d1_1) = -1.47039e-01
v(n_d1_2) = -1.47107e-01
v(n_d1_3) = -1.47043e-01
v(n_d1_4) = -1.47102e-01
v(n_d1_5) = -1.46920e-01
v(n_d1_6) = -1.47121e-01
op finished after 7.703 seconds.
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Parse finished after 44.414 seconds.
Using SPARSE 1.3 as Direct Linear Solver
Device Setup finished after 45.445 seconds.

No. of Data Rows : 1
v(n_d1_1) = -1.47036e-01
v(n_d1_2) = -1.47103e-01
v(n_d1_3) = -1.47040e-01
v(n_d1_4) = -1.47098e-01
v(n_d1_5) = -1.46915e-01
v(n_d1_6) = -1.47118e-01
ngspice 1 -> op finished after 48.910 seconds.

That's not too bad considering the huge netlist. With KLU solver it is even a bit faster.

[Chad Winters]

Thanks, but can you test on the current stable version ?

[Holger Vogt]

ngspice-44.2

spice.rc in User/user
******
** ngspice-44.2 : Circuit level simulation program
** Compiled with KLU Direct Linear Solver
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Copyright 2001-2024, The ngspice team.
** Please get your ngspice manual from https://ngspice.sourceforge.io/docs.html
** Please file your bug-reports at https://ngspice.sourceforge.io/bugrep.html
** Creation Date: Jan 11 2025   14:24:24
******
Start finished after 0.043 seconds.

Note: Compatibility modes selected: ps lt a


Circuit: ebana_circuit

Source Deck finished after 0.924 seconds.
Prepare Deck finished after 1.773 seconds.
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Parse finished after 2.607 seconds.
Using SPARSE 1.3 as Direct Linear Solver
Device Setup finished after 3.564 seconds.

No. of Data Rows : 1
v(n_d1_1) = -1.47039e-01
v(n_d1_2) = -1.47107e-01
v(n_d1_3) = -1.47043e-01
v(n_d1_4) = -1.47102e-01
v(n_d1_5) = -1.46920e-01
v(n_d1_6) = -1.47121e-01
op finished after 6.826 seconds.
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Parse finished after 41.206 seconds.
Using SPARSE 1.3 as Direct Linear Solver
Device Setup finished after 42.166 seconds.

No. of Data Rows : 1
v(n_d1_1) = -1.47036e-01
v(n_d1_2) = -1.47103e-01
v(n_d1_3) = -1.47040e-01
v(n_d1_4) = -1.47098e-01
v(n_d1_5) = -1.46915e-01
v(n_d1_6) = -1.47118e-01
ngspice 1 -> op finished after 45.476 seconds.

[Chad Winters]

I have just tried to run this on both my pc (arch linux) running ngspice 44.2 and another (ubuntu) running ngspice 42. In both of them, it just hangs. Could this be a linux this ?

Also, my version does not print the time (Device Setup finished after 42.166 seconds.) like yours.

[Giles Atkinson]

"Bad" does take some time on my Debian system, and the process is not growing, so an infinite loop seems likely. I will try it in a debug build.

Looks like a corrupted node list contains a cycle, so infinite loop at src/spicelib/analysis/cktdltn.c:36.

[Holger Vogt]

Profiling my execution says it stays in function CKTdltNNum in line 116 of vsrcset.c for 98% of the time after the first op and before the second op.

[Giles Atkinson]

Yes. It is a linked list loop. I have a function that detects the loop and can find the cause by inserting it in the "alter" code. I can take this one, but not if you want to continue digging.

Edit: Valgrind shows nothing useful (no corruption).

Thanks for the Windows build fix for the other change. I foolishly thought it was too simple to need a test build.

G.

[Holger Vogt]

Adding a 'reset' make things faster:

.control
op
print V(n_d1_1) V(n_d1_2) V(n_d1_3) V(n_d1_4) V(n_d1_5) V(n_d1_6)
reset
alter V.Xxp.V1=0
op
print V(n_d1_1) V(n_d1_2) V(n_d1_3) V(n_d1_4) V(n_d1_5) V(n_d1_6)
.endc

see

Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Parse finished after 2.568 seconds.
Using SPARSE 1.3 as Direct Linear Solver
Device Setup finished after 3.550 seconds.

No. of Data Rows : 1
v(n_d1_1) = -1.47039e-01
v(n_d1_2) = -1.47107e-01
v(n_d1_3) = -1.47043e-01
v(n_d1_4) = -1.47102e-01
v(n_d1_5) = -1.46920e-01
v(n_d1_6) = -1.47121e-01
op finished after 6.927 seconds.
Reset re-loads circuit ebana_circuit

Circuit: ebana_circuit

Source Deck finished after 7.033 seconds.
Prepare Deck finished after 7.845 seconds.
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Parse finished after 8.744 seconds.
Using SPARSE 1.3 as Direct Linear Solver
Device Setup finished after 9.721 seconds.

No. of Data Rows : 1
v(n_d1_1) = -1.47036e-01
v(n_d1_2) = -1.47103e-01
v(n_d1_3) = -1.47040e-01
v(n_d1_4) = -1.47098e-01
v(n_d1_5) = -1.46915e-01
v(n_d1_6) = -1.47118e-01
ngspice 1 -> op finished after 13.081 seconds.

The vsrc unset function obviously does not comply with 81000 voltage sources.

[Holger Vogt]

It is not the 'alter' command, but simply two 'op' in series. The second 'op' requires a voltage source reset, which does not comply well with such a large number of voltage sources. 'reset' removes the circuit completely and reloads it internally from an intermediate stage where subcircuit expansion is done already. Thus it is relatively efficient.

[Giles Atkinson]

I was getting a false positive in loop detection.

The code for partially resetting the circuit is very inefficient. CKTdltNNum() searches to the end of the list every time, even after a match was found! Performance might be improved by reversing the order of the node list, so that generated nodes that get removed here are at the front. But several things rely on the current order.