TX lines filter simulation issues

[ra3xdh]

This issues has been reported by email. It is expected nearly the same result, for the tx lines version of the attached circuit. But the S-parameters simulation shows the random noise. The root of this behavior is unknown. The schematic works correctly if the GMIN is connected to all nodes.

LPF_1GHz.zip

[felix-salfelder]

In the schematic file, there is

<R R5 1 740 410 15 -26 0 1 "10k" 1 "26.85" 0 "0.0" 0 "0.0" 0 "26.85" 0 "european" 0>.

It's not shown in the screenshot or went missing?

[ra3xdh]

The schematic file seems to be from the another version of the filter. I have just replaced it.

[felix-salfelder]

R5 wasn't the issue, but thanks!

As explained some time ago in Qucs/qucs#1094, it is hard to make sense of stuff like

<TLIN4P Line1 1 740 80 -26 -82 0 2 "65.7 Ohm" 1 "74.95 mm" 1 "0 dB" 0 "26.85" 0>

Once again the issue here is broken or unexpected connectivity. There is no need for guesswork when using explicit named connections as in

TLIN4P #(.Alpha(1.),.L(74.95m),.Temp(26.85),.Z(65.7)) Line1 (.t1(_net12),.t2(_net14),.b1(_net14),.b2(_net8));

Anyway, from the net2verilog converted netlist.txt the connection problem is way easier to spot. A working circuit and the simulation output is here.

Eventually, I get a similar numerical result with Qucsator from the fixed schematic. But only Gnucap directly hints at a problematic node in the broken one...

[tomhajjar]

Something wrong with Line1/2/3.

[ra3xdh]

The issue title and description was a bit misleading. It is obvious why the simulation fails. The schematic starts to work correctly after adding GMIN to all nodes. It is not a big problem to identify the failing node. But it is not clear why the computation algorithm becoming unstable on simple circuit. The issue should be fixed in spsolver.cpp but not on the schematic capture or netlister side.

@felix-salfelder Please don't make advertising of your new schematic file/netlist format if you cannot provide any other help. I have already answered that I am not considering the schematic format change for Qucs-S at least until you will provide a C++ implementation and APIs. And I have no wish and time to participate in its development in old Qucs project.

[felix-salfelder]

The issue title and description was a bit misleading.

Looking again, I found the bug in the TLIN4P wrapper. It's not in qucs-s or its netlister. So the issue with port connections being the root of the original problem was wishful thinking. On the bright side, gnucsator.sh gives the correct result, and works fine with qucs-s. Having two simulators helps (me) troubleshooting, please ignore the reference, if you don't need it.

It is obvious why the simulation fails.

Is it?

Qucsator only needs a single additional resistor from top of line1 to ground. In fact, the value does not matter. I haven't looked at the implementation. The behaviour hints at a bogus potential at the top node, which may be caused by a missing or broken dc model (some Spices compute operating points unnecessarily, and I am extrapolating a bit) Gnucap has both, limiting and a trln with a dc model. If you do not need Gnucap, you can still port the code over to Qucsator.