Netlist: incorrect behavior with capacitor adjoining constant analog input used as voltage source.

[colinhowell]

I do not know the origin of this behavior, but it causes incorrect computation of capacitor voltages in some circumstances, requiring a dummy resistance to work around.

Consider the following netlist, named cap-bug.cpp:

#include "netlist/devices/net_lib.h"

NETLIST_START(case1)

	SOLVER(Solver, 48000)

	ANALOG_INPUT(I_V12, 12)
	RES(R62, RES_M(1))

	CAP(C9, CAP_U(0.1))

	NET_C(I_V12.Q, C9.1)
	NET_C(C9.2, R62.1)
	NET_C(R62.2, GND)

NETLIST_END()

NETLIST_START(case2)

	SOLVER(Solver, 48000)

	ANALOG_INPUT(I_V12, 12)
	RES(R62, RES_M(1))

	// Very low-valued dummy resistance:
	RES(RDUMMY, RES_R(1))

	CAP(C9, CAP_U(0.1))

	NET_C(I_V12.Q, RDUMMY.1)
	NET_C(RDUMMY.2, C9.1)
	NET_C(C9.2, R62.1)
	NET_C(R62.2, GND)

NETLIST_END()

Both netlists case1 and case2 should behave similarly. There is no or very little resistance between the capacitor's terminal .1 and the 12-voltage voltage source, while there is a large resistance between its terminal .2 and ground. The capacitor is uncharged initially, so both of its terminals should be at the same voltage, 12 volts. Displacement current should then flow from the capacitor to ground through the large resistance, charging the capacitor and dropping the voltage of its terminal .2 to zero in an exponential falloff.

If I run the netlist case2 and log C9.2, ./nltool -c run -t 1 -l C9.2 -n case2 cap-bug.cpp, that's exactly what I see.

However, if I run case1 and log C9.2, ./nltool -c run -t 1 -l C9.2 -n case1 cap-bug.cpp, what I see is that terminal .2's voltage starts at zero and never budges. In fact the log file has only two lines:

0.000000000e+00 0.000000e+00
1.000000000e+00 0.000000e+00

This actually affected a startup circuit for a linear-feedback shift register, forcing me to add a dummy resistance.

[couriersud]

Here is the LTSpice result for case 1:

The initial solution comes up with 1.2 pico Volt, that is within numerical rounding limits. 1.2pV ~= 0V, i.e. netlist delivers the same result.

Please search for "LTSpice initial solution". This is an issue every spice program is dealing with, in reality the power supply will raise or raise swinging until it stabilized.

[couriersud]

To make things more complicated:

The only difference is the "uic" flag which skips the initial operating point calculation.
This should be how netlist works - netlist doesn't do an initial operating point calculation.
But I don't have a solution at hand. LTSpice seems to step voltage sources:

From 0V to 9V at 2fs and 12V at 4fs. Netlist starts with 12V at 0s.

[couriersud]

NETLIST_START(case1)

	SOLVER(Solver, 48000)

	VS(I_V12, 12)
	RES(R62, RES_M(1))

	CAP(C9, CAP_U(0.1))

	NET_C(I_V12.1, C9.2)
	NET_C(C9.1, R62.1)
	NET_C(R62.2, I_V12.2, GND)

NETLIST_END()

delivers the expected result matching LTSPICEs "uic" flag.
VS Voltage sources are MNA voltage sources - to be more correct current sources with a low internal resistance. The resulting matrix in this case is a 2x2 matrix. At t=0 the solution is I_V12.1=0. At the next timestep I_V12.1=12.

ANALOG_INPUT provides a fixed voltage in the voltage vector u. The unknown in this case is the current.
Recap: We solve the system G * u = i for u. Since the ANALOG_INPUT elements are known, we can eliminate one voltage from the equation and are left with a 1x1 system. This however forces a different startup condition where IV12 for t=0 is 12.