Enable printing outputs with engineering exponents
Improve error message
Example for small signal noise in code model OTA
spicious warning
Fixed in pre-master-47 2c0aabd76 ("Remove linker warnings (VS2022)", 2026-04-25)
spicious warning
Fixed in pre-master-47 2c0aabd76 ("Remove linker warnings (VS2022)", 2026-04-25)
Remove linker warnings (VS2022)
Here's a trivial scrip if you run it with a non-debug build (built with FORTIFY_SOURCE) it will core dump. As an added bonus if you run it with a debug build it will complete without crashing but show the corruption in the VCD file Paul
Show that the external process 'gnuplot' is running (Windows only)
Update to notes and error messages
Use controlled exit
Fix a bug reported by Dmitriy, replace = by ==
Show equal x axes
Fix a bug in the SFFM current source, reported by Dmitriy.
All paths return a value
Fix a bug, reported by Dmitriy
remove linker warning.
ngspice crashes in eprvcd (with fix)
Fixed in git branch pre-master-47.
I didn't bother because the code was obviously wrong :-) It's past bed time here in NZ, I'll knock a definitive one up tomorrow. But to trigger it you should do something like build ngspice without debug and do a vcd write with -a and 3 or more signals, that should trigger a crash. Paul
ngspice crashes in eprvcd with 3 or more analog parameters.
Move the memory check to a place where it is called once only per plot
Status display 'shell', if shell command takes its time.
Implement MIFnoise(), the generic noise callback for all XSPICE code
OTA (operational transconductance amplifier) code model as a
Add ota to VC analog project
Implement MIFnoise(), the generic noise callback for all XSPICE code
I didn't bother because the code was obviously wrong :-) It's past bed time here in NZ, I'll knock a definitive one up tomorrow. But to trigger it you should do something like build ngspice without debug and do a vcd write with -a and 3 or more signals, that should trigger a crash. Paul On Sat, 25 Apr 2026, 00:36 Holger Vogt, h_vogt@users.sourceforge.net wrote: Do you have a test case fro me? [support-requests:#87] https://sourceforge.net/p/ngspice/support-requests/87/ ngspice crashes in eprvcd (with...
Loop incompatibility
Do you have a test case fro me?
ngspice crashes in eprvcd (with fix)
Thanks for the patch. I will have a look.
ngspice crashes in eprvcd (with fix)
A 5th order integration method (like PLECS is using) needs 4 initial derivatives in addition to the initial value itself. IIRC, SPICE does a number of steps (with a low order integrator) to approximate these derivatives. This approximation will be inaccurate, and anyway there is no guarantee that the values are what the user intended. However, I think it reasonable to expect that SPICE-based simulators will show the same result. With SIMPWL I know for sure that it does not need unknown derivatives....
Might check that mutuals are sane. I have had trouble in other simulators in other times, trying to do complex couplings (without clue) and evidently there's some stuff about making sure matrices are sparse and the k values rolled up, still sub-unity (?). I just gave up trying to model bond wire k couplings. C, OK. L,OK. Anyway, different simulators might respond to the physically impossible in various ways. I'd dig there first, "why?". Then maybe run a "settling" tran job to get to a DC-stable or...
It is, as are others of the BSIM* devices. It seems it was too confusing for me the first time I generated a list of non-NULL DEVconvTest pointers, but it is straightforward now, so this evening I can finish completing the patch, recheck, and repost. Edit: I've added the forgotten parallel changes, rechecked and replaced the patch in my post above to avoid confusion of similarly named patches. The patch has the intended effect, in that printfs show that the differences being tested for convergence...
Attaching a completion of the repairs started in the patch already applied to pre-master-47, making the same fix in devices bjt, dio, hicum2, vbic, vdmos, (Edit: and the bsim family). I see no similar errors on other devices ( mos6, etc.). Clean make check and in my sampling through the examples, everything seems to work to me. The regression test in this patch now uses a 'dio' device instead of a user-written 'asrc' function representing a diode. Improving performance on the simulation using this...
It is, as are others of the BSIM* devices. It seems it was too confusing for me the first time I generated a list of non-NULL DEVconvTest pointers, but it is straightforward now, so this evening I can finish completing the patch, recheck, and repost.
Thanks, Felix! BTW, I tried OpenModelica and SIMBA (demo version) just now. Modelica is a monster that I can not make sense off. SIMBA gave an interesting result. The initial values are obeyed but neither the frequency nor the damping are correct. With respect to the link to Gnucap wiki: I think UIC is useful when you want to restart a simulation from a (partly) saved snapshot. I also use it to start up simulations where SPICE does not find a reasonable OP quickly enough (like for a power-factor...
If we look at b4cvtest.c, lines 56 ff. , is this the same issue?
Thanks, Felix! I'll ponder gnucap's documentation. BTW, I tried OpenModelica and SIMBA (demo version) just now. Modelica is a monster that I can not make sense off. SIMBA gave an interesting result. The initial values are obeyed but neither the frequency nor the damping are correct.
Attaching a completion of the repairs started in the patch already applied to pre-master-47, making the same fix in devices bjt, dio, hicum2, vbic, vdmos. I see no similar errors on other devices ( mos6, etc.). Clean make check and in my sampling through the examples, everything seems to work to me. The regression test in this patch now uses a 'dio' device instead of a user-written 'asrc' function representing a diode. Improving performance on the simulation using this more rigorously physically-based...
see here (Gnucap wiki). tl;dr; The issue is somewhere between model specification and simulation algorithm. The way Spice implements UIC makes no physical sense in general (cf. the currents at time 0). Particularly, (spice, ngspice) UIC was not originally intended for the purpose shown here. NB: Other simulators may do different things. Not rocket science, but at the cost of losing Spice compatibility.
see http://gnucap.org/dokuwiki/doku.php/gnucap:manual:tech:spice2verilog?s[]=uic#algorithmic_peculiarities tl;dr; The issue is somewhere between model specification and simulation algorithm. The way Spice implements UIC makes no physical sense in general (cf. the currents at time 0). Particularly, (spice, ngspice) UIC was not originally intended for the purpose shown here. NB: Other simulators may do different things. Not rocket science, but at the cost of losing Spice compatibility.
I am struggling with the simulation of a coupled inductor when initial values are specified. By now I did the same simulation (see attachment) in NGSPICE, LTspice, PLECS, and SIMPWL, with four rather different outcomes. The LTspice result is clearly completely wrong. It simply does not obey the IC=... specification when using .TRAN with the UIC option. At least the sum of the three inductor currents is 0, as it must be. This is a surprising result for this rather mature program. NGSPICE is clearly...
I am struggling with the simulation of a coupled inductor when initial values are specified. By now I did the same simulation (see attachment) in NGSPICE, LTspice, PLECS, and SIMPWL, with four rather different outcomes. The LTspice result is clearly completely wrong. It simply does not obey the IC=... specification when using .TRAN with the UIC option. At least the sum of the three inductor currents is 0, as it must be. This is a surprising result for this rather mature program. NGSPICE is clearly...
I am struggling with the simulation of a coupled inductor when initial values are specified. By now I did the same simulation (see attachment) in NGSPICE, LTspice, PLECS, and SIMPWL, with four rather different outcomes. The LTspice result is clearly completely wrong. It simply does not obey the IC=... specification when using .TRAN with the UIC option. At least the sum of the three inductor currents is 0, as it must be. This is a surprising result for this rather mature program. NGSPICE is clearly...
I am struggling with the simulation of a coupled inductor when initial values are specified. By now I did the same simulation (see attachment) in NGSPICE, LTspice, PLECS, and SIMPWL, with four rather different outcomes. The LTspice result is clearly completely wrong. It simply does not obey the IC=... specification when using .TRAN with the UIC option. At least the sum of the three inductor currents is 0, as it must be. This is a surprising result for this rather mature program. NGSPICE is clearly...
I am struggling with the simulation of a coupled inductor when initial values are specified. By now I did the same simulation (see attachment) in NGSPICE, LTspice, PLECS, and SIMPWL, with four rather different outcomes. The LTspice result is clearly completely wrong. It simply does not obey the IC=... specification when using .TRAN with the UIC option. At least the sum of the three inductor currents is 0, as it must be. NGSPICE is clearly better. The sum of the initial inductor currents is 0, and...
I am struggling with the simulation of a coupled inductor when initial values are specified. By now I did the same simulation (see attachment) in NGSPICE, LTspice, PLECS, and SIMPWL, with four rather different outcomes. The LTspice result is clearly completely wrong. It simply does not obey the IC=... specification when using .TRAN with the UIC option. At least the sum of the three inductor currents is 0, as it must be. NGSPICE
I am struggling with the simulation of a coupled inductor when initial values are specified. By now I did the same simulation (see attachment) in NGSPICE, LTspice, PLECS, and SIMPWL, with four rather different outcomes. The LTspice result is clearly completely wrong. It simply does not obey the IC=... specification when using .TRAN with the UIC option. At least the sum of the three inductor currents is 0, as it must be. NGSPICE
Info message to stdout, not stderr
Fix NULL dereference of getpwuid() result and missing tfree()
make check fails on pre-master-47 due to missing file
Fixed in pre-master-47.
Add missing
Add missing, fixes bug 839, reported by Mamoru Tasaka
Thanks! G.
2 files, attached, go in tests/regression/misc They are in the patch up-thread, so it might be easier reapply and 'git add' the two new files. I did follow up on my comment "there is a similar error in the tests for other nonlinear devices" from the top post, and in the end found only one or two copies of this error. I'll try within one day to find and recheck that completion of this patch, and then post it here.
The patch was missing a file, convergence.cir, causing Bug #839. Keith OHara, please post the file.
The patch was missing a file, convergence.cir. Keith OHara, please post the file.
Indeed, it is an effect of integrating Patch 121 (commit 0638aaa160). The file was not included in the patch. To fix, remove the file name from tests/regression/misc/Makefile.am. Thank you for the report.
PSS updates:
Some tiny updates for pss examples
make check fails on pre-master-47 due to missing file
Implement getrusage() with ru_maxrss permanently for Apple ARM.
Updating the 'available memory' measurement for Apple ARM 64 bit
OSDI array parameters lead to segmentation fault
load both standard and nqs PSP models
Update van der Pol oscillator
Improve PSS error messages
PSS: new breakpoint deletion, copied from dctran.c:
Fix a bug when evaluating -0.5^3.
Thank you for your response. Following is the result from SPICE, Note: Compatibility modes selected: ps lt a Circuit: Doing analysis at TEMP = 27.000000 and TNOM = 27.000000 Using SPARSE 1.3 as Direct Linear Solver Operating point simulation skipped by 'uic', now using transient initial conditions. Warning: command 'plot' is not available during batch simulation, ignored! You may use Gnuplot instead. No. of Data Rows : 10011 irms = 6.35351e+00 from= 1.00000e-08 to= 1.00000e-02 irms = 6.353514e+00...
Thank you for your response. I am pretty new to SPICE. I am going to try UIC
Thank you for your response. You are genius. I modified my netlist, and increase the length to 4 second. The result get much better. * Inductor RMS current measurement V1 in 0 SIN(0 282.28 50) R1 in n1 0.10 L1 n1 0 100mH .tran 0.2ms 4000ms 1000ms .control run meas tran Irms RMS i(L1) from=2000ms to=3000ms print Irms .endc .end Following is the result, Note: Compatibility modes selected: ps lt a Circuit: Doing analysis at TEMP = 27.000000 and TNOM = 27.000000 Using SPARSE 1.3 as Direct Linear Solver...
Thank you for your response, For this circuit, the theorical calculation value is, 6.37A. The margin of error is too high. I modified my netlist, and got a better result from SPICE.
Use initial conditions: * Inductor RMS current measurement V1 in 0 SIN(0 282.28 50) R1 in n1 0.10 L1 n1 0 100mH ic=-9 .tran 1us 10m uic .control run plot i(L1) meas tran Irms RMS i(L1) print Irms .endc .end
Use initial conditions: * Inductor RMS current measurement V1 in 0 SIN(0 282.28 50) R1 in n1 0.10 L1 n1 0 100mH ic=-9 .tran 10us 2 uic .control run plot i(L1) meas tran Irms RMS i(L1) print Irms .endc .end
Additionally, the simulation as is runs over only a half cycle. The calculation assumes the waveform is a full number of cycles in steady-state. Still I am slightly confused. Isn't a .TRAN (without UIC ) supposed to calculate the steady-state of the circuit? That is not happening. (Apparently the initial state not only shorts inductors and opens capacitors, but it also assumes DC sources.)
That is caused by the starting transient. Increase the length to 1 second: meas tran Irms RMS i(L1) from=0.98 to=1 Irms = 7.17735e+00 from= 9.80000e-01 to= 1.00000e+00 Plotting the current shows what happens!
10.968Arms I see also in other simulators.
Thanks! I checked the rest of the codebase — $oscompiled is only used in vlnggen, ghnggen, and the definition in init.c, so the patch should cover all affected files. Happy to make changes if needed after your testing.
Hi All, I am trying to measure the RMS current of an inductor in SPICE. Following is my simple circuit, * Inductor RMS current measurement V1 in 0 SIN(0 282.28 50) R1 in n1 0.10 L1 n1 0 100mH .tran 1us 10ms .control run meas tran Irms RMS i(L1) print Irms .endc .end And I got a valid result from SPICE. Following is the result, Note: Compatibility modes selected: ps lt a Circuit: Doing analysis at TEMP = 27.000000 and TNOM = 27.000000 Using SPARSE 1.3 as Direct Linear Solver Initial Transient Solution...
Hi All, I am trying to measure the RMS current of an inductor in SPICE. Following is my simple circuit, * Inductor RMS current measurement V1 in 0 SIN(0 282.28 50) R1 in n1 0.10 L1 n1 0 100mH .tran 1us 10ms .control run meas tran Irms RMS i(L1) print Irms .endc .end And I got a valid result from SPICE. Following is the result, Note: Compatibility modes selected: ps lt a Circuit: Doing analysis at TEMP = 27.000000 and TNOM = 27.000000 Using SPARSE 1.3 as Direct Linear Solver Initial Transient Solution...
This patch has eliminated the false convergence Giles noted on bug #824. My test circuit now fails to converge with or without the added 0V source.
Many thanks for the patch. I should try and revive my old test environment and verify MSYS, Cygwin and the rest. Perhaps dropping Cygwin can be considered, it is not mentioned much recently. (The web site suggest that Windows versions later than 2012 are not supported!) The $oscompiled error is interesting. The documentation agrees, so I think I must have copied that from somewhere. When fixed in XXXgen, the bug may be lurking elsewhere ...
Root cause analysis and patch I traced the issue to its root cause. There are actually three problems in vlnggen (and the same first one in ghnggen): $oscompiled = 1 (MINGW) is missing from the Windows detection In configure.ac, the OS values are: 1 = MINGW, 2 = Cygwin, 3 = FreeBSD, 4 = OpenBSD, 5 = Solaris, 6 = Linux, 7 = macOS, 8 = MSVC But vlnggen line 39 checks: if $oscompiled = 2 | $oscompiled = 3 | $oscompiled = 8 // Windows This misses MINGW (1) and incorrectly includes FreeBSD (3). So MSYS2/MINGW-built...
I'm using Debian 13 and gcc 14 as well.
Fix a bug introduced by yesterday's commit
It is simply a bug I have introduced with yesterday's commit https://sourceforge.net/p/ngspice/ngspice/ci/8abfb5aeb05383f693088c56d746a84ceaa16dc7/. VS2022 does not care. A fix is uploaded.
Reproduced with Debian 13/gcc 14.2 and probably compiler-specific. OS and compiler versions please.
Compilation Error in options.c
I've never used incomplete args, but for a triangle wave my workaround was just use an infinitesimal PW rather than zero. SPICE2 used to be pretty unforgiving.
Hi Holger, I think it's that one, but it's a 10years old work, so I don't remember exactly! :) It's part of my PhD, attached, along with LnL Separation (I think there is a branch for this too). Thank you, Fra
Hi Holger, no, no, because it was experimental for some models. It needs code model modification, like KLU... But we could brainstorm offline among all of us. Thank you, Fra
Which branch are you talking about? Is it 'new-kirchhoff-5' ? What is the advantage of this approach ? Do you have made some description or publication?
Is it ready for patching, or does it need further optimisation?
Hi guys, what do you think if we also include my work on KCL Verification? It's basically on the same topic of this one. Maybe we can combine it... Thank you, Fra